Re: [PATCH] Don't divide by zero when trying to destroy an uninitialised barrier.

[Mike Frysinger <vapier at gentoo dot org>]

On 26 Apr 2016 11:44, Adhemerval Zanella wrote:
> On 26/04/2016 11:38, Florian Weimer wrote:
> > On 04/20/2016 09:46 PM, Adhemerval Zanella wrote:
> >> I do not see a compelling reason to not return EINVAL if the UB
> >> could be detected and if POSIX stated this behaviour is recommended.
> > 
> > It would result in silent loss of synchronization if the return value is not checked.  Such bugs are difficult to track down.
> > 
> > Florian
> 
> But the check is user responsibility and getting such error means the
> program is doing something fuzzy.
> 
> But thinking twice seems that abort in such cases seems a better
> alternative, it gives the user a more straightforward indication
> he should check his code. 

in principal, i tend to agree with you.  but as an active counter-point,
i think we can agree that the heap corruption checks which trigger aborts
have improved software in the wider ecosystem.
	... malloc(): memory corruption (fast) ...

whether we'll see as much use in this API, it's hard to say.  but if we
already have the code in place to detect a bad/invalid scenario, then an
abort doesn't seem bad to me.  when you start adding more checks though,
then due consideration to overhead/fast paths make sense.
-mike

Attachment: signature.asc
Description: Digital signature