This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |