This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Sebastian's Patches Committed
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: sebastian dot huber at embedded-brains dot de
- Cc: joel dot sherrill at oarcorp dot com, newlib at sourceware dot org, chrisj at rtems dot org
- Date: Fri, 25 Oct 2013 21:19:02 +0200
- Subject: Re: Sebastian's Patches Committed
- Authentication-results: sourceware.org; auth=none
> From: Sebastian Huber <sebastian.huber@embedded-brains.de>
> Date: Fri, 25 Oct 2013 19:55:19 +0200
> > 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.
The inconsistency I see is that both libc/include/stdint.h and
_default_types.h "guesses" the appropriate types (well, strictly
stdint.h doesn't *guess*; it makes the call).
I think an appropriate change would be to switch roles which one
includes the other: move the type-deciding part of stdint.h to
_default_types.h and make stdint.h include that header and do
like "typedef __uint32_t uint32_t".
Maybe make use of those __INT<X>_TYPE__-like macros defined in
recent gcc when defining the __int<x>_t-line macros in
_default_types.h. Perhaps it's even ok to just do that and, as
a fallback only, cheat and include stdint.h, if
e.g. __UINT32_TYPE__ isn't defined. ;)
(To wit, AFAIU, the "_" prefix in _default_types.h is supposed
to mean "here be namespace-clean definitions only; use
underscore for everything of global scope". See the head
comment in newlib/libc/include/sys/_types.h, the including file:
"ANSI C namespace clean utility typedefs".)
> >> 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?
Well, not *that* direct; *without* affecting the global namespace.
(I was thinking of something like preprocessing and grepping the
contents of stdint.h or somesuch, maybe asserting correct
guesses. The issue is moot anyway as the stdint.h we'd
preprocess is the newlib one.)
> >> 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
Ah, you meant the test-suite, not gcc proper.
Those preprocessor macros sure look nice.
brgds, H-P