Sebastian's Patches Committed

[Hans-Peter Nilsson]

> From: Sebastian Huber <sebastian.huber@embedded-brains.de>
> Date: Fri, 25 Oct 2013 09:01:19 +0200

> On 2013-10-25 04:30, Hans-Peter Nilsson wrote:
> >> From: Joel Sherrill <joel.sherrill@oarcorp.com>
> >> Date: Tue, 15 Oct 2013 19:41:34 +0200
> >
> >> I just committed Sebastian's patches. If there are issues,
> >> just speak up. :)
> >
> > This seems wrong.  Including e.g. stdlib.h shouldn't pull in
> > stdint.h.  There's likely standards language forbidding this but
> > I don't have it right here.

7.1.3 Reserved identifiers 2 "no other identifier is reserved"
(referring to 7.1.2 "Each header declares or defines all
identifers listed in its associated subclause").  Neither 7.18
about stdint.h nor 7.20 about stdlib.h contains text that says
stdint.h is included by other headers, or that the stdint.h
types are also defined elsewhere (as opposed to e.g. stddef.h).
The contents of the stdlib.h chapter doesn't refer to any
stdint.h type AFAICS.

> > Glibc used to have such issues.
> > Such bleed is not helpful to users; they should need to include
> > the right headers, not just a random header when needing
> > e.g. uint32_t.
> 
> Yes, libc from FreeBSD uses also a clean type system that doesn't have this 
> problem.  The basic issue for Newlib is that it can use <stdint.h> provided by 
> GCC.  So from my point of view we have only two options

More imagination needed!

> 1. Use <stdint.h> from GCC and do this consistently, or

What do you mean by consistently?  Using it within compiled code
in newlib, yes.  Leaking stdint.h by using it *in installed
newlib headers* is a bug, not consistency.  The identifier
leakage is an actual bug, as opposed to the fixed wart of not
actually using the gcc stdint.h within newlib.

So, I suggest that patch be reverted but I'm open to:

> 2. do not use <stdint.h> from GCC and define the type system on our own.

3. derive the internal definitions from gcc stdint.h.

> Option 2. has the problem that GCC checks that its internal types match the one 
> in <stdint.h>.

There's no explicit check that I know of so I'm not sure to what
you're referring.

>  GCC has no general strategy to define its internal types and 
> they are target dependent (e.g. int vs. long for uint32_t).

> > Right, it affects only margin cases, but those exist.  See for
> > example gcc/testsuite/gcc.dg/20050922-1.c and -2.c on the 4.7
> > and 4.8 branch (they might be "fixed" soon to not define
> > uint32_t).
> >
> > brgds, H-P
> >
> 
> Ok, this should be fixed in the GCC test suite.

Not for the stdlib.h-then-typedef-uint32_t issue; that's a valid
case.

brgds, H-P