stdint.h & machine/types.h Header file redefinition

[Derick Hammond]

Hi Ralf:

Thanks for your comments.  I thought it might be a rather large change to 
occur this close to a release of RTEMS 4.6.0.  I will just have to put up 
with the current warnings, or work on a solution using your strategies.  At 
the moment I don't think it will be a real big problem for me.

BTW, what C standard is RTEMS favouring at the moment C89 or C99?

Regards,
Derick

At 05:47 AM 19/11/2003 +0100, Ralf Corsepius wrote:
>On Wed, 2003-11-19 at 05:10, Derick Hammond wrote:
> > Hello All:
> >
> > I have come up with a redefinition warning when I started using the
> > stdint.h header file.
> >
> > A little background:
> >
> > I use the multilib compiled version of the RTEMS libraries for m68k, 
> and my
> > own build system that  links to the appropriate libraries.
>
>Then you're on your own.
>
> >   Much like using
> > the AMX RTOS, or any commercial RTOS for that matter.  :-)
>
>
> > The current warning that I get is:
> >
> > /opt/rtems-4.6/bin/m68k-rtems-gcc -m5200 -O4 -fomit-frame-pointer -Wall -g
> > -ansi -fasm -DBOOTSTRAP
> > 
> -I/home/derickh/cvs_wa/DataVault_Firmware/devtools/rtems/m68k-rtems/lib/include 
>
> > -I/home/derickh/cvs_wa/DataVault_Firmware/firmware/include
> > -I/home/derickh/cvs_wa/DataVault_Firmware/firmware/rom_start
> > -I/home/derickh/cvs_wa/DataVault_Firmware/firmware/startup -o
> > 
> /home/derickh/cvs_wa/DataVault_Firmware/firmware/../library/rom_objs/rom_start/main.o 
>
> > -c /home/derickh/cvs_wa/DataVault_Firmware/firmware/startup/main.c
> > In file included from
> > 
> /home/derickh/cvs_wa/DataVault_Firmware/devtools/rtems/m68k-rtems/lib/include/stdint.h:16,
> >                   from
> > 
> /home/derickh/cvs_wa/DataVault_Firmware/devtools/rtems/m68k-rtems/lib/include/rtems/rtems/types.h:26,
> >                   from
> > 
> /home/derickh/cvs_wa/DataVault_Firmware/devtools/rtems/m68k-rtems/lib/include/rtems.h:39,
> >                   from
> > /home/derickh/cvs_wa/DataVault_Firmware/firmware/include/tod/tod.h:33,
> >                   from
> > /home/derickh/cvs_wa/DataVault_Firmware/firmware/startup/main.c:32:
> > 
> /home/derickh/cvs_wa/DataVault_Firmware/devtools/rtems/m68k-rtems/lib/include/rtems/stdint.h:21: 
>
> > warning: redefinition of `int8_t'
> > /opt/rtems-4.6/m68k-rtems/include/machine/types.h:18: warning: `int8_t'
> > previously declared here
> > 
> /home/derickh/cvs_wa/DataVault_Firmware/devtools/rtems/m68k-rtems/lib/include/rtems/stdint.h:22: 
>
> > warning: redefinition of `int16_t'
> > /opt/rtems-4.6/m68k-rtems/include/machine/types.h:17: warning: `int16_t'
> > previously declared here
> > 
> /home/derickh/cvs_wa/DataVault_Firmware/devtools/rtems/m68k-rtems/lib/include/rtems/stdint.h:23: 
>
> > warning: redefinition of `int32_t'
> > /opt/rtems-4.6/m68k-rtems/include/machine/types.h:15: warning: `int32_t'
> > previously declared here
> > 
> /home/derickh/cvs_wa/DataVault_Firmware/devtools/rtems/m68k-rtems/lib/include/rtems/stdint.h:24: 
>
> > warning: redefinition of `int64_t'
> > /opt/rtems-4.6/m68k-rtems/include/machine/types.h:11: warning: `int64_t'
> > previously declared here
> >
> > I have had a quick investigation and have found that machine/types.h seems
> > to only be used in cpukit/libnetworking.  Is this correct?
>
>Yes and no.
>
>machine/types.h is one of RTEMS fundamental and essential internal
>system headers that is used all over the place. It is indirectly
>included at various places.
>
> >   If so can
> > libnetworking be updated to use stdint.h instead?
>I wish it could be, but ...
>
>... you have entered muddy ground here were the problems reach much
>deeper than you probably expect.
>
>* libnetworking and other parts of the sources are BSD-sources. BSD has
>its own system for fixed-size types.
>
>* stdint.h is c99. newlib is c89, machine/types.h is part of newlib.
>I.e. all parts of
>
>* Historically, RTEMS has been using it own type-system for fixed size
>types.
>
>All this accumulates inside of libnetworking, where all fixed size type
>systems are used simultaneously and ... actually clash ...
>
>So what actually would be required is to change libnetworking from using
>BSD-types to c99 types, to convert RTEMS as a whole to c99 types, and
>find a way to implement stdint.h inside of RTEMS to avoid problems with
>gcc and newlib.
>
>This change is on my agenda for 4.7.0, once 4.6.0 is released.
>
>The stdint.h implementation in 4.6.0pre is a preliminary and not fully
>functional initial attempt to implement this, but is far from being
>complete.
>
> > I am happy to do a patch for rtems-4.6.0pre5 if I can get some feedback on
> > what would be considered the best way to solve this issue.
>I have spent more than a few hours on this issue, and wish I knew that.
>
>My current strategy for 4.7.0 to implement this, is:
>* let stdint.h types be derived from the RTEMS type system.
>* replace all occurrences of the RTEMS type system by stdint.h types.
>* remove the BSD-fixed-type system (this comprises converting
>libnetworking to using stdint.h)
>
>I have many patches related to this pending in my local sources, and
>don't want commit them to the official development sources before 4.6.0
>is released.
>
>Ralf