OSDev.org

Posted: **Tue Sep 28, 2004 11:32 am**

A while ago now I created a GCC cross-compiler. Recently, I wanted to use <stdbool.h>, and it worked fine. Then I wanted to use <stdint.h>, and noticed that it doesn't seem to be there (i.e. -- in the cross-compiler directory). So, can I conclude that for whatever reason, a cross-compiler with no library support still provides stdbool.h, but not stdint.h? If so, why? AFAIK, they both just contain type definitions... so why one and not the other? (I just wanted to use uint16_t and other nice C99 type names without having to define my own.)

Posted: **Wed Sep 29, 2004 12:23 am**

Colonel Kernel wrote: So, can I conclude that for whatever reason, a cross-compiler with no library support still provides stdbool.h, but not stdint.h?

Actually, a compiler does not provide any headers. Unfortunately, the GNU people like to ignore borderlines between their tools.

In a "perfect" world, you would have the GCC on your Linux box (which doesn't know zilch about any headers or standard functions), a standard library implementation, and a Linux library.

However, in reality you have the GCC which implements several standard functions as "builtins", and a "GNU" C Library mingling standard C functions with lots of POSIX and "GNUish" extensions.

The Cross-Compiler how-to in the FAQ shows you how to set up the GCC for a different target. There is no standard library (since you would have to implement or port one to your OS), so the compiler should balk at anything that is C library as opposed to C language. <stdbool.h>, now, is very much a no-brainer (true -> 1, false -> 0, bool -> _Bool), so the GCC people implemented it "inline". <stdint.h>, on the other hand, is very much platform-dependent, so it's part of what you will have to implement / port.

This, of course, shows why it is so much a bad idea to deduct working -> correct. A C library for your OS would have to include <stdbool.h>, because you cannot assume that every C compiler people might use with your library has <stdbool.h> built in.

HTH.

Posted: **Wed Sep 29, 2004 11:10 am**

Solar wrote:
The Cross-Compiler how-to in the FAQ shows you how to set up the GCC for a different target. There is no standard library (since you would have to implement or port one to your OS), so the compiler should balk at anything that is C library as opposed to C language. <stdbool.h>, now, is very much a no-brainer (true -> 1, false -> 0, bool -> _Bool), so the GCC people implemented it "inline". <stdint.h>, on the other hand, is very much platform-dependent, so it's part of what you will have to implement / port.

Sometimes it's a very fine line between "language" and "library". In this case, I see nothing "platform-specific" per se about stdint.h... Architecture-specific, yes, but that's ok... The target architecture for my kernel is x86, and the target of the cross-compiler is i586-elf... So why should this be a problem?

This, of course, shows why it is so much a bad idea to deduct working -> correct. A C library for your OS would have to include <stdbool.h>, because you cannot assume that every C compiler people might use with your library has <stdbool.h> built in.

You mean include and not #include, right?

Just to clarify, I'm not creating a C library for my OS, at least not in the sense of creating something consumable from user-mode. I've just started coding in the kernel itself, and I want language support, not libraries. (By language support, I basically mean auxiliary type definitions like bool, uint16_t, etc.).

Posted: **Wed Sep 29, 2004 9:03 pm**

Sometimes it's a very fine line between "language" and "library".

No doubt, but in this case there isn't.

C is clearly defined to the n[sup]th[/sup] degree in the standard. Anything outside the specifications is NOT standard C and falls under the realm of user defined code. This is why things like getch() are not standard C even though they may be available from your favourite C compiler.

Posted: **Wed Sep 29, 2004 11:14 pm**

Curufir wrote: No doubt, but in this case there isn't.

C is clearly defined to the n[sup]th[/sup] degree in the standard. Anything outside the specifications is NOT standard C and falls under the realm of user defined code.

I am quite sure that <stdint.h> is part of the C99 standard. All the hits on Google suggest this, anyway. Unfortunately, I don't have my own copy of the standard, but I did find a quote from someone who refers to it (chapter & verse, so to speak):

"section 7.18 of the C99 standard (ISO/IEC 9899:1999)"

If anyone out there has a copy of the C99 standard, can you please confirm...?

My understanding about how the standardization of libraries works comes mostly from the C++ world... There, I believe the STL is part of the language standard itself, but it is optional for a conforming implementation. I would expect C99 to work the same way...

Posted: **Wed Sep 29, 2004 11:57 pm**

Colonel Kernel wrote:
Sometimes it's a very fine line between "language" and "library". In this case, I see nothing "platform-specific" per se about stdint.h...

What went into the language and what went into the library doesn't really have to do with platform- or architecture-specific. Fact is that extending the library is much easier for all involved than extending the language, including compatibility considerations. Hence, most of the things that were added after the initial K&R C were added to the library - including bool and uint32_t.

Just to clarify, I'm not creating a C library for my OS, at least not in the sense of creating something consumable from user-mode. I've just started coding in the kernel itself, and I want language support, not libraries. (By language support, I basically mean auxiliary type definitions like bool, uint16_t, etc.).

Well, but that is in the library, not the language. The language defines char, short, int, long, and (in C99) long long, nothing else (as far as integers are concerned).

I am quite sure that <stdint.h> is part of the C99 standard.

Correct.

"section 7.18 of the C99 standard (ISO/IEC 9899:1999)"

Uh-huh.

If anyone out there has a copy of the C99 standard, can you please confirm...?

I can confirm that chapter 7 of the standard defines the library.

My understanding about how the standardization of libraries works comes mostly from the C++ world... There, I believe the STL is part of the language standard itself, but it is optional for a conforming implementation. I would expect C99 to work the same way...

That's not quite correct, not for C++ and not for C. An implementation can be either freestanding or hosted.

A hosted implementation means the whole shebang: Language, library, runtime, initializing statics and globals, registering functions with atexit(), entering at int main() with stdout and stdin etc. etc. pp.

A freestanding implementation doesn't have to provide any of the runtime support, but still has to support the language, and a defined subset of the library - in case of C99, that would be float.h, iso646.h, limits.h, stdarg.h, stdbool.h, stddef.h, and stdint.h.

Note, however, that this is still the library. A compiler doesn't have to know anything about the library. After all, you might want to exchange the glibc with newlib or the Dinkumware library, because they are faster / threadsafe / more precise in their maths, no? So, the compiler mustn't assume anything about the library.

There we are again. The Cross Compiler you built is a cross-compiler. No library there.

So anything defined in chapter 7 of the standard needn't be there. If it is, that's because the GCC implementors took some ("implementation-defined") liberties around the edges.

Hope I could clarify this now.

Posted: **Thu Sep 30, 2004 1:05 am**

Keep in mind that, in the earliest versions of the language, C didn't have any concept of a library header - the #include function, and all preprocessor functions, were provided by a separate program. The use of headers was originally only a convention, not a part of the language. IIRC, it wasn't until the first ANSI standard that the preprocessor was a required part of the language; even now, the cpp(1) is a separate utility in many C compiler packages, even if the preprocessor actually used is internal to the compiler.

Nor were the 'standard' libraries part of the language definition prior to that; some popular early compilers, such as Small-C and BDS C (the name, which was a pun on BSD, stood for 'Brain-Damaged Software', IIRC), had completely incompatible libraries, and few compiler packages supported the whole library suite.

Posted: **Thu Sep 30, 2004 5:51 pm**

I think we're just dealing with slightly different terminology here. I apologize for any confusion... By "compiler", I meant the compiler proper, and everything that comes with it. In the case of the GCC cross compiler that I built, that includes this directory:

/usr/cross/lib/gcc/i586-elf/3.4.1/include

Which contains these files:

Code: Select all

total 135
-rw-r--r--    1 Bruce    None          750 Aug 28 05:49 README
-rw-r--r--    1 Bruce    None        34525 Aug 28 05:49 emmintrin.h
-rw-r--r--    1 Bruce    None           10 Aug 28 05:49 fixed
-rw-r--r--    1 Bruce    None         5360 Aug 28 05:49 float.h
-rw-r--r--    1 Bruce    None         1428 Aug 28 05:49 iso646.h
-rw-r--r--    1 Bruce    None         2745 Aug 28 05:49 limits.h
-rw-r--r--    1 Bruce    None        22281 Aug 28 05:49 mmintrin.h
-rw-r--r--    1 Bruce    None         3586 Aug 28 05:49 pmmintrin.h
-rw-r--r--    1 Bruce    None         4313 Aug 28 05:49 stdarg.h
-rw-r--r--    1 Bruce    None         1600 Aug 28 05:49 stdbool.h
-rw-r--r--    1 Bruce    None        13025 Aug 28 05:49 stddef.h
-rw-r--r--    1 Bruce    None          330 Aug 28 05:49 syslimits.h
-rw-r--r--    1 Bruce    None         8892 Aug 28 05:49 unwind.h
-rw-r--r--    1 Bruce    None          139 Aug 28 05:49 varargs.h
-rw-r--r--    1 Bruce    None        30855 Aug 28 05:49 xmmintrin.h

More on this later.

By "language", I mean everything in the standards document. I guess I meant library as well, particularly in the freestanding case. Sorry for the confusion.

Now, back to these mysterious files... There is a README that says this:

This README file is copied into the directory for GCC-only header files when fixincludes is run by the makefile for GCC.

Many of the files in this directory were automatically edited from the standard system header files by the fixincludes process. They are system-specific, and will not work on any other kind of system. They are also not part of GCC. The reason we have to do this is because GCC requires ANSI C headers and many vendors supply ANSI-incompatible headers.

Because this is an automated process, sometimes headers get "fixed" that do not, strictly speaking, need a fix. As long as nothing is broken by the process, it is just an unfortunate collateral inconvenience. We would like to rectify it, if it is not "too inconvenient".

This is a bit vague and confusing to me, but I assume it is pertinent to our discussion.

So, if headers such as stdbool.h aren't even supposed to be there, how can I re-direct the search path for #include <yaddayadda> so that it doesn't pick up this rogue version...?

Posted: **Thu Sep 30, 2004 10:19 pm**

With -I {include path}. (Untested, as I am in the midst of installing Linux - again - and don't have a cross-compiler handy atm.)
The beauty with most of those "freestanding" headers, though, is that there isn't much you can want to do different. That's why they are part of the "freestanding" environment.

Posted: **Thu Sep 30, 2004 10:54 pm**

Solar wrote:
With -I {include path}. (Untested, as I am in the midst of installing Linux - again - and don't have a cross-compiler handy atm.)

-I works fine for include paths in double-quotes, but not for those in angle brackets AFAIK.

The beauty with most of those "freestanding" headers, though, is that there isn't much you can want to do different. That's why they are part of the "freestanding" environment.

...except for <stdint.h> (the reason I brought this up in the first place)! ??? First I'm supposed to avoid using these handful of headers, and now I should use them? I'm confused by all the flip-flops!

I suppose I could write my own stdint.h, but I can't see how it would be materially different than the one that comes with the flavour(s) of GCC I have. I don't want to just copy it, due to issues with the GPL... <sigh> Not difficult, just a pain.

<edit>
nm about the GPL issues... there is a special clause in there that would make my kernel (in binary form) exempt. I wouldn't be able to redistribute the .h files though...
</edit>

Posted: **Thu Sep 30, 2004 11:09 pm**

Colonel Kernel wrote:
Solar wrote:
With -I {include path}. (Untested, as I am in the midst of installing Linux - again - and don't have a cross-compiler handy atm.)
-I works fine for include paths in double-quotes, but not for those in angle brackets AFAIK.

They most certainly do. Try out any of my source files (atlantisos), I use it for the entire kernel include tree.

...except for <stdint.h> (the reason I brought this up in the first place)! ??? First I'm supposed to avoid using these handful of headers, and now I should use them? I'm confused by all the flip-flops!

I suppose I could write my own stdint.h, but I can't see how it would be materially different than the one that comes with the flavour(s) of GCC I have. I don't want to just copy it, due to issues with the GPL... <sigh> Not difficult, just a pain.

<edit>
nm about the GPL issues... there is a special clause in there that would make my kernel (in binary form) exempt. I wouldn't be able to redistribute the .h files though...
</edit>

It won't be different. The idea behind an ANSI C compatible header is that you cannot do it different from others. Guess what part of Linux SCO thought they copied?

Pretty obvious of course, if I make a stdint header and then claim copyright over that code, it's pretty equivalent or even equal to others code for the same function. That doesn't make it against the copy right.

For the GPL stuff, you can, afaik, always redistribute headers. They are never linked against any program and are most certainly not in your program. As long as they don't contain any code, they can't be affected by it.

But then again, IANAL.

The idea behind these headers is that they give you a common working environment, where most people (me too, atm) first set up an incompatible environment where the only difference is the header structure and the type names. That should be quite doable to change, thereby creating a lot of coherence between almost all C code.

Posted: **Fri Oct 01, 2004 12:59 am**

Candy wrote:
For the GPL stuff, you can, afaik, always redistribute headers. They are never linked against any program and are most certainly not in your program. As long as they don't contain any code, they can't be affected by it.

The FSF made it rather clear, on numerous occassions, that header files are to be considered source code, i.e. #including them means building a derived product...

Note that this is FSF lingo. I consider that BS, but then again, that's true for most of the FSF.

As soon as my Linux is up and running, I will dig a bit into GCC internals to find how to suppress those headers. as to avoid future confusions.

Posted: **Fri Oct 01, 2004 10:09 am**

Solar wrote:The FSF made it rather clear, on numerous occassions, that header files are to be considered source code, i.e. #including them means building a derived product...

Where, precisely, have they made that assertion? It contradicts the actual text of the LGPL, where they clearly state that it is legally unclear whether #including headers constitutes a derived work (and thus feel compelled to specify that, at least in the cast of the LGPL, the use of such headers leads to an unrestricted work, regardless of what the legal threshold might be).

See http://www.gnu.org/copyleft/lgpl.html section 5, noting specificly the words may, whether this is true, and threshold... not precisely defined by law.

So, as far as I can find from official statements made by the FSF, their position is that it's unknown whether #including results is a derived work or not. If nothing else, they seem to openly acknowledge that there's a threshold under which it would certainly be considered not.

If they've contradicted this position elsewhere, I'd be very interested in reviewing the link. (Hotheads spouting personal opinions on message boards or mailing lists probably doesn't qualify, but I'd love to see it anyhow...)

Posted: **Mon Oct 04, 2004 12:24 am**

From the LGPL:

When a "work that uses the Library" uses material from a header file that is part of the Library, the object code for the work may be a derivative work of the Library even though the source code is not. Whether this is true is especially significant if the work can be linked without the Library, or if the work is itself a library.

This is the LGPL, which allows to keep your code under your own licensing as long as it can be shipped seperately (so you can link it with a modified version of the LGPL'ed library). The headers, in this case, are the "legal" interface to the LGPL part. (And even there they speak of a "threshold"...)

The generic GPL doesn't allow for that kind of seperate shipment, so it could be (and has been) argued that by #include'ing GPL'ed headers, you are using GPL'ed source code.

If they've contradicted this position elsewhere, I'd be very interested in reviewing the link. (Hotheads spouting personal opinions on message boards or mailing lists probably doesn't qualify, but I'd love to see it anyhow...)

I admit that a quick & dirty Google search came up empty, and I'm too busy / lazy / unsure about my point to look deeper into it. Since most aspects of the GPL have never been tried in court, I just wouldn't bet my money on it.

Posted: **Mon Oct 04, 2004 2:29 pm**

GCC is GPL, yes, but from stdbool.h in gcc distribution:

/* As a special exception, if you include this header file into source
files compiled by GCC, this header file does not by itself cause
the resulting executable to be covered by the GNU General Public
License. This exception does not however invalidate any other
reasons why the executable file might be covered by the GNU General
Public License. */

Similar notice is in the other headers included with GCC.
Rest of the standard library is GLIBC which is LGPL.

OSDev.org

Headers available w/ GCC cross-compiler

Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler

Re:Re:Headers available w/ GCC cross-compiler

Re:Re:Headers available w/ GCC cross-compiler

Re:Re:Headers available w/ GCC cross-compiler

Re:Re:Headers available w/ GCC cross-compiler

Re:Re:Headers available w/ GCC cross-compiler

Re:Headers available w/ GCC cross-compiler