[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc

From: Joshua Scholar
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
Date: Mon, 4 Jan 2021 09:21:41 -0800

Does this mean that TCC works with CLang includes and libraries on Linux-arm, Linux-arm64, Linux x64, Linux-riscv, FreeBSD-x64, FreeBSD-arm64, NetBSD-x64, and NetBSD-arm64? 

That would be very useful.  I mentioned wondering before but didn't get a useful answer.

It's amazing that you have access to 12 setups including a RiscV one!

On Fri, Jan 1, 2021 at 10:57 PM Christian Jullien <eligis@orange.fr> wrote:

Here is the result of my study when stddef.h no longer contains [u]intN_t definitions.


i.e. b) solution


OS      | cpu   | Compilers     | result (including compiling OpenLisp with installed tcc)


Linux   | arm   | gcc/clang/tcc | Ok

Linux   | arm64 | gcc/clang/tcc | Ok

Linux   | x64   | gcc/clang/tcc | Ok

Linux   | riscv | gcc/clang/tcc | Ok

FreeBSD | x64   | gcc/clang/tcc | Ok

FreeBSD | arm64 | gcc/clang/tcc | Ok

NetBSD  | x64   | gcc/clang/tcc | Ok

NetBSD  | arm64 | gcc/clang/tcc | Ok

OpenBSD | x64   | gcc/clang     | Ok

macOS   | x64   | clang         | Ok

Windows | x64   | gcc/tcc       | Ok obvious as it uses its own stddef.

Windows | x86   | gcc/tcc       | Ok obvious as it uses its own stddef.


* Linux x86 build is missing but I doubt it will change things

* Some OpenBSD and macOS don’t fully support tcc boostrapped by tcc.


Do you allow me to remove [u]intN_t definitions for stddef.h and see how it goes? It at least seem to solve the issue of incompatible [u]intN_t redefinitions.

I’m not in favor to add stdint.h which looks to not be needed.





-----Original Message-----
From: Christian Jullien [mailto:eligis@orange.fr]
Sent: Saturday, January 02, 2021 06:36
To: 'tinycc-devel@nongnu.org'
Subject: RE: [Tinycc-devel] issues/questions with stddef.h which comes with tcc


Thank you for your long  reply which confirms what I thought.

So I really think now that stddef.h should only contain what C11 officially defines and let tcc rely on [/usr/include/]stdint.h definitions.

I made a quick test without [u]intN_t definition and tcc after installed in /usr/local/lib/tcc is quite happy at least on linux/arm.

It can be used to bootstrap tcc and its test suite, it also compiles my OpenLisp test suite w.o. a single warning.


I suspect it is not the case with all supported platforms (Apple, *BSD).

I'll check all of them and return to you with a complete feedback.




-----Original Message-----

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange.fr@nongnu.org] On Behalf Of Michael Matz

Sent: Saturday, January 02, 2021 00:09

To: jullien@eligis.com; tinycc-devel@nongnu.org

Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc




On Fri, 1 Jan 2021, Christian Jullien wrote:


> First, happy new year all.


To you as well.


> Porting tcc on *BSD systems raised issues/questions with stddef.h from tcc

> distrib.


> First, it contains a mix of definitions coming from both stddef.h and

> stdint.h IMHO it should only contain what stddef.h is supposed to contain.


First some background.  TLDR: patches welcome :)


Standard headers are a bit complicated when considering the C library and

the C compiler in isolation (which we need to do with TCC, as we provide

only a compiler).  Both are part of a standard describing the whole

implementation, of library and compiler.  But some header facilities can

be usefully provided only with compiler knowledge.  There's the concept of

free-standing implementations, that need to provide only a few headers

(<stddef.h> being one), and it's such that in those headers are the most

compiler specifics.  So it's sensible to provide them with the compiler,

not with the C library (and if only for the reason that if you don't even

have a C library that you can use the free-standing part of the C



You will notice that also GCC provides it's own <stddef.h>.


<stdint.h> is a mixed bag; most of it's facilities can be nicely defined

without many compiler specifics except very few crucial macros/builtins.

So, many C libraries do in fact provide that header themself, but still in

a way that there are compilers that don't work correctly with them.  E.g.

GCC provides a <stdint.h> that uses the library one with a hosted

implementation (the opposite of a free-standing one).


There's also an advantage for the C library providing these headers: they

can in addition to the standard facilities also provide means that are

specific to the library implementation (e.g. the whole _GNU_SOURCE

business in the GNU C library).


So, for some headers there's a grey zone for decisions: should the

compiler or the library provide a header.  For <stddef.h> it's easy: also

other system compilers provide it, e.g. also because of the offsetof()

macro that needs compiler support when you want to avoid non-portable

implementations, so TCC should provide it.  For <stdint.h>: here it's less

clear: TCC doesn't claim to provide a free-standing implementation, so it

doesn't _have_ to provide it, but could rely on the C library, which we do

right now.


But of course you are right in that the TCC <stddef.h> should not provide

anything that it isn't supposed to provide, as that can cause conflicts

like you are seeing.


Several solutions:

a) make the non-standard extensions of TCC <stddef.h> be conditional on a

    macro (or a non-existence of a macro, like e.g. it could continue to

    provide them outside C89/C99/C11 conformance).

b) remove those additions completely

c) b + provide own <stdint.h>

d) b + leave it to the C library to provide <stdint.h>


The nicest solution would be (c) as that goes towards providing a

free-standing implementation.  But the provided <stdint.h> needs to be

compatible with anything the C libraries provide or rely on.  GCC has to

jump through hoops with that (using include_next), that might be historic

cruft, or it might still be for a reason, I don't know.  So without trying

on a range of platforms I can't say if (c) is realistic or not.



> Why tcc needs its own stddef.h instead of system one?


See above, the system one also is compiler specific.


> Why tcc does not need stdint.h?


Because we got away with it :)  Patches welcome.


> I suppose it is because tcc does not support all gcc syntaxes found on

> stddef.h (is it still true?) in that case, it would be better to split

> definitions in stddef.h and stdint.h following the ISO C11 standard.







Tinycc-devel mailing list



Tinycc-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]