|
From: | Christian Jullien |
Subject: | Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc |
Date: | Sat, 2 Jan 2021 07:57:09 +0100 |
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. Christian. -----Original Message----- 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. C. -----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 Hello, 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 standard). 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. Ciao, Michael. _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel |
[Prev in Thread] | Current Thread | [Next in Thread] |