Re: stdint.h

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On Mon, 2005-09-19 at 22:11 -0400, Christopher Faylor wrote:
> On Tue, Sep 20, 2005 at 03:57:32AM +0200, Ralf Corsepius wrote:
> >On Mon, 2005-09-19 at 21:36 -0400, Christopher Faylor wrote:
> >> On Tue, Sep 20, 2005 at 02:52:24AM +0200, Ralf Corsepius wrote:
> >> >On Mon, 2005-09-19 at 18:02 -0400, Jeff Johnston wrote:
> >> >> Shaun Jackman wrote:
> >> >> > Could stdint.h be moved from newlib/libc/sys/rtems/include to
> >> >> > newlib/libc/include? It's a very useful header, and the rtems
> >> >> > implementation looks portable.
> >> >> >
> >> >> 
> >> >> Sure.  Just checked in.
> >> ><surprized/>
> >> >
> >> >In this case, you probably also will want to move RTEMS inttypes.h,
> >> >because stdint.h alone is only half of the story.
> >> >
> >> >@Corinna: I recall we discussed this generalization, several months ago,
> >> >but agreed upon this step to potentially interfere with Cygwin.
> >> >Does this cause any problems for Cygwin?
> >> 
> >> It will, at the very least, conflict with cygwin's file of the same
> >> name.
> >
> >Let me put it this way:
> >
> >* Theoretically, the RTEMS stdint.h/inttypes.h should be able to replace
> >Cygwin's stdint.h/inttypes.h, but I haven't checked the details nor do I
> >have any possibility to test (I don't have Windows nor do I use Cygwin,
> >except that I have and occasionally use Linux->Cygwin cross compilers).
> 
> I really don't see any need to use the RTEMS stuff especially given
> the "it's not broke" principle.
Well, the RTEMS stdint.h/inttypes.h aren't specific to RTEMS.

They had been developed as part of RTEMS and are used by RTEMS, but they
are supposed to be general headers. They just have an RTEMS history,
that's all - Just like other headers in newlib have a Sun Microsystems
or else past/history.

I.e. they are supposed to replace customized and OS-specific headers.

> >* Technically, you probably should be able (untested) to override
> >generalized headers in newlib, by putting your headers into
> >newlib/libc/sys/cygwin/include
> >(RTEMS uses a similar approach to override some general newlib headers
> >with customized headers).
> 
> This isn't a big deal.  Cygwin's headers will override the ones in newlib
> when they are installed.  Perhaps "conflict" is too strong a word.  There
> is at least one other case where a header in newlib has the same name as
> one in cygwin.  The only time it presents a problem is when you install
> newlib without subsequently installing cygwin.
> 
> I guess this will present a problem if/when more source files in newlib start
> using these headers if there is something defined in newlib's header which
> isn't in cygwin's.  We can deal with that when it happens, though.
OK. The crucial point is, some components in GCC want to use them (and
already do so) them when bootstrapping GCC or incrementally building
GCC. 

So generalizing these headers, could have an impact on building Cygwin
and definitely will impact _all_ generic newlib-based targets (*-elf).

Ralf