Re: [PATCH][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.

[Joseph Myers <joseph at codesourcery dot com>]

On Sat, 30 Jan 2016, Alexander Cherepanov wrote:

> But we can consider something much more real: glibc code contains many cases
> of undefined behavior (according to C11). I consider it bugs unwanted in
> production (maybe with the exception of strlen) but it's not clear to me what
> is the POV of the project on this. E.g., are bug reports about UB are welcome?

It's an intrinsic part of implementing the C library that it involves 
doing things that are not defined in ISO C (the ISO C library cannot all 
be implemented in ISO C).

If something involves undefined behavior in GNU C, on systems with the 
properties that hold for all systems supported by glibc (e.g. 32-bit int, 
32-bit or 64-bit long and pointers), for inputs to library functions where 
the library function semantics don't involve undefined behavior, taking 
due account of both separate compilation and use of asm to reduce the 
information available to the compiler in certain places and so make things 
not undefined that would otherwise be undefined, then I'd consider bug 
reports appropriate.  Examples of this include buffer overruns and signed 
integer arithmetic overflow.  I think that applies even if there is no 
plausible optimization that could result in the signed integer arithmetic 
overflow causing problems.  Of course, patches are even better.

If something is fully defined in GNU C, but undefined, unspecified or 
implementation-defined in ISO C, I don't think bug reports are 
appropriate.  E.g., it's not a bug for glibc code to rely on signed shifts 
by a nonnegative amount that's less than the width of the type, including 
the aspects of those that are not defined by ISO C, or on the 
fully-defined nature of conversions of out-of-range integer values to 
signed integer types.  Some such cases in code shared with gnulib (or 
other external sources) may still be gnulib bugs where they aren't glibc 
bugs, since gnulib is meant to be much more portable.  And there may be 
cases where you could argue that eliminating such usages is a desirable 
*cleanup* in glibc - e.g., that the code is cleaner when it uses unsigned 
types for bitwise operations.  But in such cases there is not bug and so 
patches should be sent without any bug reports in Bugzilla (or more 
general groups of issues identified in the list of possible cleanups in 
the todo list on the wiki).

Where something depends on a property common to all systems supported by 
glibc, again it may be a useful *cleanup* to make this more explicit in 
the code, without there being any *bug* that's appropriate to report to 
Bugzilla.  E.g., if code is using int in a way that requires it to be 
exactly 32-bit, changing the code to use int32_t is a sensible cleanup; if 
it really does mean int but is hardcoding the value of INT_MAX, making it 
use INT_MAX is a sensible cleanup; if it's using long as a pointer-sized 
integer type, changing it to use intptr_t is a sensible cleanup.

Where glibc code relies on separate compilation to avoid undefined 
behavior, this is not a bug; use of LTO on glibc's own code is not 
supported.  For example, where functions with different C types but 
compatible ABIs are aliased, or a function is otherwise defined with a 
different type from that used when it is called.  Similarly, asm may be 
used to limit code movement, and that could e.g. mean that aliasing is not 
undefined behavior where it would otherwise be undefined.

Of course, if the semantics for a function say that certain inputs result 
in undefined behavior, it does not matter if C-level undefined behavior 
occurs within that function for those inputs.

-- 
Joseph S. Myers
joseph@codesourcery.com