https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888
--- Comment #51 from David Brown <david at westcontrol dot com> --- (In reply to M Welinder from comment #48) > It's your (1). gcc is changing a program that can rely on errno not being > changed to one where the C library can change it. (The current C library or > any future library that the resulting binary may be dynamically linked > against.) > > Is there any real-world situation that benefits from introducing these > calls? It has the feel of optimizing for a benchmark. There are several real-world benefits from transforming back and forth between library calls for this kind of small standard library function. One is that turning explicit code into library calls can give smaller code - often of importance in small embedded targets. Sometimes it can also result in run-time improvements, especially for larger data sizes - user-written code might just copy byte by byte, while the library implementation uses more efficient larger blocks. Another is that turning library calls into inlined code can speed up code by using additional knowledge of sizes, alignment, etc., to get faster results. This is most obvious for calls to memcpy() or memmove(), which can sometimes be required to get the semantics correct for type manipulation, but may generate no actual code at all. A "C implementation" consists of a compiler and a standard library in tandem. The C library can make use of its knowledge of the C compiler, and any special features, in its implementation. (This is, in fact, required - some things in the standard library cannot be implemented in "pure" C.) The C compiler can make use of its knowledge of the library implementation in its code generation or analysis. For the most part, compilers only make use of their knowledge of the specifications of standard library functions, but they might also use implementation details. This means it is quite legitimate for the GCC team to say that gcc requires a C library that does not set errno except for functions that explicitly say so in their specifications. Users don't get to mix and match random compilers and random standard libraries and assume they form a conforming C implementation - the pair must always be checked for compatibility. The question then is if this would be an onerous requirement for standard library implementations - do common existing libraries set errno in functions that don't require it? I cannot say, but I would be very surprised if they did. Modern thought, AFAIUI, considers errno to be a bad idea which should be avoided whenever possible - it is a hinder to optimisation, analysis, and parallelisation of code, as well as severely limiting C++ constexpr and other compile-time calculations. My thoughts here are that GCC should make this library requirement explicit and public, after first confirming with some "big name" libraries like glibc, newlib and muslc. They could also add a flag "-funknown-stdlib" to disable any transforms back or forth between standard library calls, and assume nothing about the calls (not even what is given in the standards specifications). (As a note - the paragraph 7.5p3 allowing standard library functions to set errno is still in the current draft of C23.)
