issues/questions with stddef.h which comes with tcc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

issues/questions with stddef.h which comes with tcc

Christian Jullien-3

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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
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.  I haven't been here long, but it does sound like a bad idea to not include your own include files for every platform. 

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. Does Clang work? Is it a license issue?  If so, that's passing the license issue on to you.

On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
In reply to this post by Christian Jullien-3
I had this experience the other day.
Someone on Github is building a (not yet finished) jit compiler that has a C compiler as a test case.  It will be a competitor to TCC one day, I guess.
Anyway, it's being developed on Linux but some early parts were tested on Windows.
Not the C compiler though, it doesn't come with ANY include files.
I tried MingW's include files - nothing but errors.
I tried TCC's include files - nothing but errors.

So that's an example of this sort of thing going wrong.

On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Ivo van Poorten
On Fri, 1 Jan 2021 08:27:10 -0800 Joshua Scholar
<[hidden email]> wrote:
> I had this experience the other day.
> Someone on Github is building a (not yet finished) jit compiler that
> has a C compiler as a test case.

Do you have a link? Always interested in this kind of projects.

Regards,
Ivo

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
In reply to this post by Joshua Scholar
https://github.com/vnmakarov/mir

I mentioned all the sorts of things I wanted in a jit (along with saying that I could help) to the author of this jit and he said he wasn't interested. 
He doesn't particularly want to generate parallel friendly code, nor is he interested in a garbage collector, nor in making the state of a system open to snapshotting.

On Fri, Jan 1, 2021 at 8:27 AM Joshua Scholar <[hidden email]> wrote:
I had this experience the other day.
Someone on Github is building a (not yet finished) jit compiler that has a C compiler as a test case.  It will be a competitor to TCC one day, I guess.
Anyway, it's being developed on Linux but some early parts were tested on Windows.
Not the C compiler though, it doesn't come with ANY include files.
I tried MingW's include files - nothing but errors.
I tried TCC's include files - nothing but errors.

So that's an example of this sort of thing going wrong.

On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
In reply to this post by Ivo van Poorten
But one thing that's interesting about his project is that it compiles very fast AND it has some optimization.

He added only two optimization passes but says that on a SpecInt test, it's 80% as fast as GCC -O2
He says that most optimizations give you very little in return, but a couple of well chosen ones are worth it.

On Fri, Jan 1, 2021 at 8:50 AM Ivo van Poorten <[hidden email]> wrote:
On Fri, 1 Jan 2021 08:27:10 -0800 Joshua Scholar
<[hidden email]> wrote:
> I had this experience the other day.
> Someone on Github is building a (not yet finished) jit compiler that
> has a C compiler as a test case.

Do you have a link? Always interested in this kind of projects.

Regards,
Ivo

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Christian Jullien-3
In reply to this post by Joshua Scholar

The Windows case is more clear to me, as windows does not have compiler hence no standard includes, the win32/include part contains all the stuff to let tcc find its includes (most of its includes). It contains std C headers and the most common windows headers.

 

My concern is with includes that are installed with “make install” and go to /usr/local/lib/tcc by default.

 

C.

 

From: Joshua Scholar [mailto:[hidden email]]
Sent: Friday, January 01, 2021 17:24
To: [hidden email]; [hidden email]
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc

 

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.  I haven't been here long, but it does sound like a bad idea to not include your own include files for every platform. 

 

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. Does Clang work? Is it a license issue?  If so, that's passing the license issue on to you.

 

On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
I compiled it under linux. There is no /usr/local/lib/tcc.
I can't find anything like that.  I can't find any environment variables that refer to tcc.
And nothing was copied back to include in the build directory.

On Fri, Jan 1, 2021 at 9:13 AM Christian Jullien <[hidden email]> wrote:

The Windows case is more clear to me, as windows does not have compiler hence no standard includes, the win32/include part contains all the stuff to let tcc find its includes (most of its includes). It contains std C headers and the most common windows headers.

 

My concern is with includes that are installed with “make install” and go to /usr/local/lib/tcc by default.

 

C.

 

From: Joshua Scholar [mailto:[hidden email]]
Sent: Friday, January 01, 2021 17:24
To: [hidden email]; [hidden email]
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc

 

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.  I haven't been here long, but it does sound like a bad idea to not include your own include files for every platform. 

 

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. Does Clang work? Is it a license issue?  If so, that's passing the license issue on to you.

 

On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
In reply to this post by Christian Jullien-3
Oh, nevermind.  I never tried "sudo make install."

On Fri, Jan 1, 2021 at 9:13 AM Christian Jullien <[hidden email]> wrote:

The Windows case is more clear to me, as windows does not have compiler hence no standard includes, the win32/include part contains all the stuff to let tcc find its includes (most of its includes). It contains std C headers and the most common windows headers.

 

My concern is with includes that are installed with “make install” and go to /usr/local/lib/tcc by default.

 

C.

 

From: Joshua Scholar [mailto:[hidden email]]
Sent: Friday, January 01, 2021 17:24
To: [hidden email]; [hidden email]
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc

 

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.  I haven't been here long, but it does sound like a bad idea to not include your own include files for every platform. 

 

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. Does Clang work? Is it a license issue?  If so, that's passing the license issue on to you.

 

On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
In reply to this post by Christian Jullien-3
I responded too soon.

There are only the nine files from the build directory's /include in /usr/local/lib/tcc

That STILL doesn't tell us where it's getting stddef.h from, except that it has to be getting them from the standard GCC installed.

On Fri, Jan 1, 2021 at 9:13 AM Christian Jullien <[hidden email]> wrote:

The Windows case is more clear to me, as windows does not have compiler hence no standard includes, the win32/include part contains all the stuff to let tcc find its includes (most of its includes). It contains std C headers and the most common windows headers.

 

My concern is with includes that are installed with “make install” and go to /usr/local/lib/tcc by default.

 

C.

 

From: Joshua Scholar [mailto:[hidden email]]
Sent: Friday, January 01, 2021 17:24
To: [hidden email]; [hidden email]
Subject: Re: [Tinycc-devel] issues/questions with stddef.h which comes with tcc

 

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.  I haven't been here long, but it does sound like a bad idea to not include your own include files for every platform. 

 

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. Does Clang work? Is it a license issue?  If so, that's passing the license issue on to you.

 

On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Michael Matz-4
In reply to this post by Christian Jullien-3
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Michael Matz-4
In reply to this post by Joshua Scholar
Hello,

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?

No.

> 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.


Ciao,
Michael.

>
> On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>
_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Christian Jullien-3
In reply to this post by Michael Matz-4
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=[hidden email]] On Behalf Of Michael Matz
Sent: Saturday, January 02, 2021 00:09
To: [hidden email]; [hidden email]
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Christian Jullien-3
In reply to this post by Michael Matz-4

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-----
From: Christian Jullien [mailto:[hidden email]]
Sent: Saturday, January 02, 2021 06:36
To: '[hidden email]'
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.

 

C.

 

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

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=[hidden email]] On Behalf Of Michael Matz

Sent: Saturday, January 02, 2021 00:09

To: [hidden email]; [hidden email]

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

[hidden email]

https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

grischka
Christian Jullien wrote:
> Do you allow me to remove [u]intN_t definitions for stddef.h and see
> how it goes?

In tinycc to remove things that are unnecessary or ugly is always
allowed.  Not allowed is to add things that are unnecessary or ugly.

Also, tip of the year: While still working in progress for something, the

     'git add --amend ...'

option can be very helpful to correct mistakes or review an idea
already before one would push the push button finally.

For happiness with less #ifdefs,

--- grischka

>
> Christian.


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
In reply to this post by Michael Matz-4
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 <[hidden email]> wrote:
Hello,

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?

No.

> 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.


Ciao,
Michael.

>
> On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
In reply to this post by Michael Matz-4
And I want to mention that there's a license problem for people who want to embed Tiny C in a product if they have to use GCC headers, since GCC is full GPL.

It would be nice to supply people with a solution to that real problem.

On Fri, Jan 1, 2021 at 3:30 PM Michael Matz <[hidden email]> wrote:
Hello,

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?

No.

> 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.


Ciao,
Michael.

>
> On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien <[hidden email]> 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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Joshua Scholar
In reply to this post by Christian Jullien-3
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 <[hidden email]> 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.

 

Christian.

 

 

-----Original Message-----
From: Christian Jullien [mailto:[hidden email]]
Sent: Saturday, January 02, 2021 06:36
To: '[hidden email]'
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.

 

C.

 

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

From: Tinycc-devel [mailto:[hidden email]=[hidden email]] On Behalf Of Michael Matz

Sent: Saturday, January 02, 2021 00:09

To: [hidden email]; [hidden email]

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

[hidden email]

https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Ivo van Poorten
In reply to this post by Joshua Scholar
On Mon, 4 Jan 2021 09:12:20 -0800 Joshua Scholar
<[hidden email]> wrote:
> And I want to mention that there's a license problem for people who
> want to embed Tiny C in a product if they have to use GCC headers,
> since GCC is full GPL.

I have the impression that you do not know the difference between
compiler headers and libc headers.

You don't need GCC compiler headers for tcc.

If you use glibc and its headers, all is fine. Both tcc and glibc are
licensed under the LGPL.
 
> It would be nice to supply people with a solution to that real
> problem.

You can also use other libc implementations, like bionic or musl. If
that doesn't work at first, that means there are bugs to be fixed.
Either in the library, or in tcc.

This separation of concerns is not obsolete. It's in the latest C17
standard.

Regards,
Ivo

P.S. an extreme example: it is not guaranteed by the C standard that you
can link object files compiled by different compilers, say clang, gcc,
icc and tcc. That's because the implementation dependent stuff can
differ between compilers, and then all hope is lost.

Compiler headers define those differences. libc headers define the rest.



_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Reply | Threaded
Open this post in threaded view
|

Re: issues/questions with stddef.h which comes with tcc

Christian Jullien-3
In reply to this post by Joshua Scholar

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…


C.

 

From: Joshua Scholar [mailto:[hidden email]]
Sent: Monday, January 04, 2021 18:22
To: [hidden email]; [hidden email]
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 <[hidden email]> 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.

 

Christian.

 

 

-----Original Message-----
From: Christian Jullien [mailto:[hidden email]]
Sent: Saturday, January 02, 2021 06:36
To: '[hidden email]'
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.

 

C.

 

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

From: Tinycc-devel [mailto:[hidden email]=[hidden email]] On Behalf Of Michael Matz

Sent: Saturday, January 02, 2021 00:09

To: [hidden email]; [hidden email]

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

[hidden email]

https://lists.nongnu.org/mailman/listinfo/tinycc-devel

_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


_______________________________________________
Tinycc-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
12