This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug malloc/22611] malloc/tst-realloc wrongly assumes that errno must not be modified in case of success
- From: "aurelien at aurel32 dot net" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 16 Dec 2017 12:19:30 +0000
- Subject: [Bug malloc/22611] malloc/tst-realloc wrongly assumes that errno must not be modified in case of success
- Auto-submitted: auto-generated
- References: <bug-22611-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=22611
--- Comment #9 from Aurelien Jarno <aurelien at aurel32 dot net> ---
(In reply to Carlos O'Donell from comment #8)
> (In reply to Florian Weimer from comment #7)
> > (In reply to Aurelien Jarno from comment #6)
> > > (In reply to Florian Weimer from comment #3)
> > > > (In reply to Aurelien Jarno from comment #0)
> > > > > tst-realloc tests, among others things that malloc and friends to not set
> > > > > errno to ENOMEM in case of successful memory allocation. This test always
> > > > > fail on sparc64 with "Error: errno is set but should not be".
> > > >
> > > > Isn't this test invalid?
> >
> > > Do you mean this is correct to set ENOMEM even when malloc is successful?
> >
> > Yes, I think as long as we do not set errno to zero on success, we can
> > clobber errno. POSIX explicitly says that applications should check errno
> > only after failure (or if the function specification provides additional
> > scenarios where it has a defined value).
>
> You are right. I forgot about this wile reviewing.
>
> Only for functions whose return value cannot be disambiguated from an error
> should we set errno to 0, and then check it after the call e.g. atoi.
>
> For reference:
> https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=87152351
Thanks for the pointer. This clearly show that tst-realloc must be fixed. I
have therefore changed the title of the bug, and I'll send a patch soon.
--
You are receiving this mail because:
You are on the CC list for the bug.