[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: Christian Jullien
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
Date: Mon, 4 Jan 2021 18:58:19 +0100

Yup! I test them all for nearly every commits, or at least when I think a commit may break something.

I have access to much more than 12 setups, most of them are mine others are from gnu farm.


My OpenLisp compiler has been compiled on over 160 gnu triplets. The most uncommon are: zLinux, z/OS390, QNX, vms, HP pa risk, Alpha OS, SGI…



From: Joshua Scholar [mailto:joshuascholar@gmail.com]
Sent: Monday, January 04, 2021 18:22
To: jullien@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc


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]