Re: Sebastian's Patches Committed

[Sebastian Huber <sebastian dot huber at embedded-brains dot de>]

On 10/25/2013 05:13 PM, Hans-Peter Nilsson wrote:
> > 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:

I am fine with reverting the patch and I will work on a better solution.

> > 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.

What do you mean with derive?  Isn't this what my patch does?

> > 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.

These ones:

gcc/testsuite/gcc.dg/c99-stdint-5.c
gcc/testsuite/gcc.dg/c99-stdint-6.c

[...]

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.