https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082
--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 19 Dec 2023, fw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113082 > > --- Comment #2 from Florian Weimer <fw at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #1) > > Joseph - I wonder if the standard folks can be convinced to amend most > > library function documentation as to not altering 'errno' (like memcpy, > > strlen, etc.)? > > > > Should we simply document our constraints on supported library > > implementations? > > We can add attributes to the glibc headers, similar to the throw and leaf > annotation we have today. It would act as a reminder that if we clobber errno > in these functions due to some implementation detail, we need to save/restore > errno. I guess a new 'noerrno' attribute would make sense. What I've always wanted is also a reliable way to distinguish accesses to 'errno' from other accesses (unfortunately 'errno' is an lvalue so it's address can be taken). glibc uses __errno_location (), so an additional attribute indicating the function returns the address of 'errno' would be nice to have as well ('errno', just like we have 'malloc' for malloc results?). At the moment we can just use TBAA ('errno' is an lvalue of type 'int') for disambiguation but 'int' is a bit generic for that to be of much help.
