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

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160426/407b24b4/attachment.sig>