This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: RTEMS patch sweep: stdint.h/inttypes.h
- From: Ralf Corsepius <ralf dot corsepius at rtems dot org>
- To: Nicholas Wourms <nwourms at netscape dot net>
- Cc: Newlib List <newlib at sources dot redhat dot com>
- Date: Mon, 07 Mar 2005 06:42:31 +0100
- Subject: Re: RTEMS patch sweep: stdint.h/inttypes.h
- References: <1FEC5568.3579AA69.00213C57@netscape.net>
On Sun, 2005-03-06 at 18:30 -0500, Nicholas Wourms wrote:
> Why is machine/_types.h in a shared directory?
>
> I guess what I'm saying is: what is the point of adding these defines
> globally if they are only being used by rtems?
They are not only used by RTEMS.
* machine/_types.h is a BSD-feature.
* __intXX_t and __uintXX_t types are BSD-types.
Sources having been derived from BSD offen apply them instead of their
POSIX counterparts (stdint.h/inttypes.h), because these types predate
C99 and stdint.h/inttypes.h had not been available on pre-c99 systems.
> This stuff is really platform specific
> and shouldn't be filled with crazy ifdef logic.
This approach avoids having to use separate "machine/_types.h" files,
which I consider to be a nightmare to maintain.
They simply are too error-prone, esp. on non-mainstream targets.
> However, it seems the damage is done, so I've come up with another
> idea. A better soultion would be to add a "machine" directory for
> each platform and put it there.
This is the approach, which I consider to be crazy, to use your words. I
prefer generic solutions and prefer to avoid specializations/table-based
approaches whenever possible.
> That way, each platform could modify it to their needs. This is how
> GLIBC does it, so I see no reason why we can't.
I don't see any reason to do so, the stuff in machine/_types.h is
generic and doesn't need to be handled separately.
Ralf