[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:05:48 -0800

I'm not buying this.

Every operating system is supposed to come with a C runtime library and C include files that work on that specific OS and on every possible standard C compiler?

You think C compilers are still that privileged?  People don't even USE C anymore.  I'm sure that was perfectly true in the 70's.

Also by now there are only a few C++ compilers that are keeping up.  There's Gnu there's the new Clang, there's Microsoft and there's Intel.   I doubt there are any more.  On non-intel there's probably only Gnu and Clang.  If you are willing to use obsolete standards I'm sure there is old software hanging on for dear life.

And so the question is, depending on the platform, which ones of two to four available compiler's run time and include files does TCC work with.

And so the answer is going to be either:
1) Gnu and only Gnu. 
2) Gnu and Clang
3) oops, it doesn't work.

On Fri, Jan 1, 2021 at 3:30 PM Michael Matz <matz.tcc@frakked.de> wrote:

On Fri, 1 Jan 2021, Joshua Scholar wrote:

> I noticed that in the win32 directory there are 46 include files in the main
> include directory, 9 in include/sys, there's a secure api directory with 12
> files, an a libtcc directory with an include file and a def file.. but the
> include directory for the non-windows build only has 9 files, so I guess
> it's relying on the system to have another C compiler installed whose .h
> files it can use.

No, it means you have to have a C library installed (there are multiple).
The compiler doesn't provide one.  If you come from Windows that might
seem unusual, but the C standard explicitely has provisions for this, and
it's the usual way of delivery on non-windows system.  You might have
multiple compilers, all using the same C library, the latter being more
tied to the system facilities than a compiler.  It does require some
cooperation between C library and C compiler at the overlap, but it
provides much better separation of concerns.

> I haven't been here long, but it does sound like a bad idea to not
> include your own include files for every platform.

How could it be any different?  We don't provide a graphical GUI library,
so we provide no headers for it.  We don't provide a C library either, so
we don't provide those headers either.

The headers you see for Windows and its msvcrt library are a mere nicety:
there's only one de-facto C library on Windows so providing headers for
that one is fairly easy.  In addition there're also well-known other
libraries provided on every windows system, so some headers (and .def)
files for them are provided as well.  But that's more catering to
expectations of Windows users than the usual way.

> Does that mean you have to have GCC installed?


> It's awfully confident of them to be sure that every GCC include tree
> will work.

Not every GCC include tree, no.  But every C library include tree: yes,
that is an expectation.  Within limits, but generally so: the C lib
include headers are expected to make use of only standard C features (or
use non-standard features only after checking for availability from the
compiler at hand), and TCC is expected to conform to the standard.  Again,
that's the ideal, not 100% reached, but it's the general direction.

> Does Clang work?

With what?  With GCC include trees: no, with C lib includes: yes.  Clang
is not different from TCC in this respect, or from GCC for that matter.
It's just another compiler.  (Well, in fact clang implements most GCC
extensions, so it is even fine with most GCC-specific headers; but
that's a detail).

> Is it a license issue?  If so, that's
> passing the license issue on to you.

No, it's not a license issue, it's a separation of concern issue.


> On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <eligis@orange.fr> wrote:
>       First, happy new year all.
>       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.
>       i.e. From C11:
>       B.18 Common definitions <stddef.h>
>       ptrdiff_t
>       size_t
>       max_align_t
>       wchar_t
>       NULL
>       offsetof(type, member-designator)
>       _ _STDC_WANT_LIB_EXT1_ _
>       rsize_t
>       Howerver it also contain many [u]intN_t type definitions which
>       duplicate what is found on stdint.h
>       The issues come when a valid program frist includes <stdint.h>
>       then <stddef.h>
>       It first finds [u]intN_t definitions in system
>       [/usr/include/]stdint.h file which are duplicated/redefined in
>       [tcc/include/]stddef.h from tcc.
>       When definitions differ, tcc stops as some with *BSD systems and
>       [u]int64_t definitions.
>       Questions:
>       Why tcc needs its own stddef.h instead of system one?
>       Why tcc does not need stdint.h?
>       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.
>       Clarifications/fixes are welcome.
>       C.
> _______________________________________________
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Tinycc-devel mailing list

reply via email to

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