This is the mail archive of the
mailing list for the newlib project.
Re: Sebastian's Patches Committed
- From: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: joel dot sherrill at oarcorp dot com, newlib at sourceware dot org, chrisj at rtems dot org
- Date: Fri, 25 Oct 2013 09:01:19 +0200
- Subject: Re: Sebastian's Patches Committed
- Authentication-results: sourceware.org; auth=none
- References: <201310250230 dot r9P2UQOT024384 at ignucius dot se dot axis dot com>
On 2013-10-25 04:30, Hans-Peter Nilsson wrote:
From: Joel Sherrill <email@example.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. 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
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
1. Use <stdint.h> from GCC and do this consistently, or
2. do not use <stdint.h> from GCC and define the type system on our own.
Option 2. has the problem that GCC checks that its internal types match the one
in <stdint.h>. 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
Ok, this should be fixed in the GCC test suite.
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 : firstname.lastname@example.org
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.