This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Alexander Cherepanov <ch3root at openwall dot com>
- Cc: Dwight Guth <dwight dot guth at runtimeverification dot com>, <libc-alpha at sourceware dot org>
- Date: Sun, 31 Jan 2016 16:12:53 +0000
- Subject: Re: [PATCH][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.
- Authentication-results: sourceware.org; auth=none
- References: <27c31890079f41775175b94a4abedb0c dot squirrel at server316 dot webhostingpad dot com> <alpine dot DEB dot 2 dot 10 dot 1601282115100 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_1_dQ5D1QrKQN0pVPzt001WmS4BgwcKZkULK8XnbEMb+g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282246340 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_3rAudocTEbtZQpVoDcWgm_ww3KcX6j9XCkSRTZVPTUMg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282251350 dot 6102 at digraph dot polyomino dot org dot uk> <20160128225845 dot GE14840 at vapier dot lan> <alpine dot DEB dot 2 dot 10 dot 1601282311351 dot 6102 at digraph dot polyomino dot org dot uk> <20160128234356 dot GH14840 at vapier dot lan> <56AAB6CE dot 8060101 at openwall dot com> <20160129005816 dot GK14840 at vapier dot lan> <56AC16C8 dot 4030202 at openwall 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