Custom C library - what does the compiler provide?

[max]

Hey guys,

so we started to create a custom C library. The question is: how can I find out what is provided by the compiler (usually), and what do I have to declare myself?

For example, when creating the "stdint.h", I have to write a lot of typedefs; but GCC for example has macros like "__UINT8_TYPE__" that contain the proper type... is it correct here to simply use these?

How do you handle these things? I see that many libraries are creating their own stdint.h with custom declarations for everything, but then I'd also had to check the architecture etc.; isn't it easier to use the compilers macros here?

Greets,
Max

[JulienDarc]

First, beware of the licence when linking to gcc headers.

Second, if you plan to pick on gcc some of the macros, you will tie yourself with it. May be a problem or not.

Third, you can point to the gcc directory, the one upper from the include directory, and in your c library having #include <gcc_version/include/stdint.h> (yep, ugly).

And include the folder -I path/to/gcc/ (do not point to the include)

It enables to clearly differentiate your sources by forcing the #include written above and help the compiler choose.

Now, you will have to be very careful not to redefine symbols.

In the end, it is a "dangerous" game. You will have to test your program with every gcc version change. They may have changed something your includes may not like.

That is how I would do it. Actually, I would not do it.

[iansjack]

First, beware of the licence when linking to gcc headers.

That comment needs some explanation. What is there to beware of?

[Candy]

isn't it easier to use the compilers macros here?

Would be, if they'd actually export them on every platform.

[JulienDarc]

Yes, I was a bit expeditive on that point, sorry for being misleading.

What will be the licence of your library ? Will it be redistributed ?

-> GPL compliant ? go buddy, go go go
-> Non GPL compliant ? You will likely fall under the runtime library exception anyway. Provide a dynamic library (safe bet). Do not modify anything to gcc, just include. Roll-on.

You should be safe.

Except a lawyer tells you otherwise for your specific usecase. Licencing is tricky.

Side point : take care of being tied too tightly to one compiler. It can become a headache.

[no92]

I'm not an expert, but I suspect that you can only use standalone headers in your C lib (e.g. stdarg.h). As for defining types in stdint.h etc., you can use predefined macros.

Please don't rely on my information, I'm not sure by myself what can be used and what not.

[xenos]

In fact, <stdint.h> is also a freestanding header, so there's no reason not to use the one from GCC, unless you want to create one which has different contents: C Library.

[JulienDarc]

I happen to have a machine on which <stdint.h> merely redirects to the libc or any c library the toolchain can point to.

So relying on gcc header is a dangerous bet if you ask me. It depends on so many configurations.. granted, the usual ones coming with the distros may/will fit, but not for everyone.

My 2 cts,

Julien

[Candy]

@JulienDarc same here. It'll work for x86 / x86_64, but it doesn't work on ARM for me. So I have to make it anyway - and then I might as well make it for x86 / x86_64 as well.

Unreliable == I won't rely on it.