On Tue, 5 Nov 2024, Jakub Jelinek wrote:
> On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote: > > > POSIX semantics for malloc involve errno. > > > > So if I can check errno to see if malloc failed, I guess even our > > current behaviour of optimizing away paired malloc+free calls provided > > that the return value is unused is problematic under POSIX same way as > > the proposed patch. > > I think the unconditional malloc+free case is fine. > errno may be randomly modified by any function which doesn't fail, except > for a few special cases (like atoi etc.). Not quite randomly: it is never reset back to zero by POSIX functions, and... > So, one can't really rely on a specific value in errno after a malloc/free > pair unless one actually checks the return value of malloc and relies on > errno only if it returned NULL. > Unless it is something where one relies that the malloc must have definitely > failed and in code in between the malloc and free saves the errno value > (because after free it is certainly undefined again). free is not allowed to modify errno if passed a valid argument: [CX] The free() function shall not modify errno if ptr is a null pointer or a pointer previously returned as if by malloc() and not yet deallocated. https://pubs.opengroup.org/onlinepubs/9799919799/functions/free.html Alexander
