Sebastian's Patches Committed

[Sebastian Huber]

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.