C was designed to be a portable language, and as such, C compilers can be found for most architectures and Operating systems.
Examples of things that are system dependent are endianess, bytesize, integer size, and pointer size.
So while the contents of <stdio.h> will likely be the same across platforms and architectures, the content of those header files that define the hardware to the compiler will always vary.
GCC hiding standard C header files
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
AFAI can see, after rummaging around more sets of header files than I care to recall over the years, architecture-specific adaptation of headers is readily, if not always entirely straightforwardly, effected by defining a (sometimes large) number of scalar parameters as macros and then conditionally compiling headers as chunks of code that are conditionally included according to the values of those parameters.jafadmin wrote:C was designed to be a portable language, and as such, C compilers can be found for most architectures and Operating systems.
Examples of things that are system dependent are endianess, bytesize, integer size, and pointer size.
So while the contents of <stdio.h> will likely be the same across platforms and architectures, the content of those header files that define the hardware to the compiler will always vary.
It is technically possible to do this without having to separate any standard headers from the compiler install package, as is routine practice in all commercially supported compilers that I have looked into. Indeed the typical practice for commercial, multi-targettable embedded C compilers, is to give a complete set of architecture-dependent standard headers for each supported target architecture - and often for different chip variants within a single architecture.
Given that there is no technical necessity for separation of standard headers from the rest of the compiler, I am at a loss to see why gcc seems to think it a good thing to do - unless as far as gcc is concerned, POSIX is the only platform they are concerned with. This, of course, makes it far harder than necessary to create verifiably repeatable installed compiler configurations, the absence of which is utter anathema in the development of critical systems.
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?
Run these two commands from a console to produce all the info about the linux gcc compiler environment:
Code: Select all
#touch a.c
#gcc -v -E a.c
Some symbolic links might help like I did here:
http://murga-linux.com/puppy/viewtopic. ... 688#992688
http://murga-linux.com/puppy/viewtopic. ... 688#992688
-
- Posts: 276
- Joined: Thu 29 Mar 2018, 22:13
- Location: West Wales bandit country
Thanks. This is helpful. Although it isn't acceptable for certification-level testing, it does tell me a lot about how I can design an environmental enquiry program to obtain the required configuration information by acceptable means (i.e. by running a conforming C test program that discovers what the config is rather than simply by asking gcc to say it).jafadmin wrote:Run these two commands from a console to produce all the info about the linux gcc compiler environment:Code: Select all
#touch a.c #gcc -v -E a.c
I'm currently putting together a prototype system written in Tcl that will generate the required conforming C test programs. More when I've got it up and running and have played with it a bit.
###### Added 23:54 GMT+1 2018-05-22
I've got the first results from my Tcl test system and have started a new thread entitled
Determining C compiler implementation characteristics #####
Sometimes I post mindfully, sometimes not mindfully, and sometimes both mindfully and not mindfully. It all depends on whether and when my mind goes walkies while I'm posting :?