This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Sebastian's Patches Committed

On 10/25/2013 05:13 PM, Hans-Peter Nilsson wrote:
From: Sebastian Huber <>
Date: Fri, 25 Oct 2013 09:01:19 +0200
On 2013-10-25 04:30, Hans-Peter Nilsson wrote:
From: Joel Sherrill <>
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:



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  :
PGP     : Public key available on request.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]