Sebastian's Patches Committed
Fri Oct 25 19:19:00 GMT 2013
> From: Sebastian Huber <email@example.com>
> 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:
Ah, you meant the test-suite, not gcc proper.
Those preprocessor macros sure look nice.
More information about the Newlib