On Thu, 27 Jun 2024 13:23:50 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

bart <bc@freeuk.com> writes:

On 26/06/2024 13:15, Ben Bacarisse wrote:

bart <bc@freeuk.com> writes:

On 25/06/2024 16:12, David Brown wrote:

...

I /do/ use Python. I use it when it is an appropriate language
to use, which is very different circumstances from when I use C
(or C++). Different tools for different tasks.

And yet neither of you are interested in answering my question,
which was why its simplistic bytecode compiler is acceptable in
this scenario, but would be considered useless if applied to C
code.

You throw out a lot of these sorts of question, by which I mean
questions that you either /do/ know the answers to or which you
/should/ know the answers to.

If a software engineering student asked me this sort of "challenge"
question it would immediately become homework: come up with at
least two scenarios in which a simplistic C bytecode compiler
would be an unacceptable tool to use, and two in which Python with
a trivial bytecode compiler would be an acceptable tool to use.
In each case explain why. Anyone who could not would get marked
down on the course.

I'm not sure what you're implying here.

Some here are consistently saying that any compiler whose internal processes are not at the scale or depth that you find in
professional', 'industrial scale' products like gcc, clang, icc, is
not worth bothering with and is basically a useless toy.

After reading the above I decided to try tcc. I used tcc for
the first time earlier today.

First I tried using tcc for my most recent project. That
didn't go anywhere, because that project relies on C11,
and tcc doesn't support C11.

Next I tried using tcc on a small part of my larger current
project. That test involves compiling one .c file to produce a
.o file, and linking with several other .o files to produce an
executable, and running the executable. The .c file being
compiled uses C99 and doesn't need C11.

The first thing that came up is tcc doesn't support all of
C99. There are some C99 features that tcc just doesn't
understand. In this case the infringements were minor so I
edited the source to work around the missing features.

The second thing to come up is some language incompatibilities.
There are language features that tcc understands, sort of,
but implements them in a way that didn't work with my source
code. To be fair, a case could be made that what tcc does
conforms to the C standard. However, the code I had before
works fine with gcc and clang, and doesn't with tcc. Here
again the changes needed were minor so I edited the source
to work around the problem.

The third thing to come up was the link step. Compiling the
one .c file with tcc -- and there are three other .o files
produced using gcc -- implicated the link step, which needed
to be done with tcc to avoid some undefined symbols. That
kind of surprised me; I'm used to being able to mix gcc
object files and clang object files with no difficulty,
so having the link step fail caught me off guard.

After taking care of all that the build did manage to produce an
executable, which appears to have run successfully.

After doing a trial run with the produced executable, I looked at
the tcc man page. As best I can tell, tcc simply silently
ignores the -fPIC option. (I didn't test that, I only read what
the tcc man page says.) That project absolutely relies on -fPIC,
so if tcc doesn't support it that's a deal breaker.

Not offering any conclusion. Just reporting my experience.

I tried tcc too.

1. It is easy to download. It does not need installation apart from
unzip.

2. It is very fast. Even when used from makefile, which is not an
optimal mode of use, in my tests more than 3 times faster than MSVC in non-parallel build and more that twice faster in parallel build on
quad-core CPU. And that on project that spends unproportionally long
time in link. I am ready to believe that on more typical projects
(i.e. more compile time, less link time) the difference would be over
5x.
For the record, on this project 'gcc -O2' was ~1.7x slower than 'MSVC
-O2' and 'gcc -O0' was ~1.1x slower than 'MSVC -O2'; the later
difference probably because somewhat faster compilation by 'gcc -O0' was outdone by much slower link.

3. Exe is slow, but not slower than gcc -O0. About the same. In this
particular test it meant ~2.5 times slower than optimized gcc or MSVC
binary.


4. In this particular project I encountered few inconvenient
incompatibilities:
4.1. no support for %zd and %zu. May be, Linux version is better in that regard?
4.2. Code like below does not compile. I don't know whether it is legal
'C' or not,
but gcc, clang and MSVC compilers accept it o.k.
label:int bar;
4.3. c11/c17 things that are supported even by MSVC, which is generally
does not claim full C11 support:
_Alignof()

It's close to advertised, i.e. it is not C17, but has few features of
C17.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Thu, 27 Jun 2024 13:23:50 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

bart <bc@freeuk.com> writes:

On 26/06/2024 13:15, Ben Bacarisse wrote:

bart <bc@freeuk.com> writes:

On 25/06/2024 16:12, David Brown wrote:

...

I /do/ use Python. I use it when it is an appropriate language
to use, which is very different circumstances from when I use C
(or C++). Different tools for different tasks.

And yet neither of you are interested in answering my question,
which was why its simplistic bytecode compiler is acceptable in
this scenario, but would be considered useless if applied to C
code.

You throw out a lot of these sorts of question, by which I mean
questions that you either /do/ know the answers to or which you
/should/ know the answers to.

If a software engineering student asked me this sort of "challenge"
question it would immediately become homework: come up with at
least two scenarios in which a simplistic C bytecode compiler
would be an unacceptable tool to use, and two in which Python with
a trivial bytecode compiler would be an acceptable tool to use.
In each case explain why. Anyone who could not would get marked
down on the course.

I'm not sure what you're implying here.

Some here are consistently saying that any compiler whose internal
processes are not at the scale or depth that you find in
professional', 'industrial scale' products like gcc, clang, icc, is
not worth bothering with and is basically a useless toy.

After reading the above I decided to try tcc. I used tcc for
the first time earlier today.

First I tried using tcc for my most recent project. That
didn't go anywhere, because that project relies on C11,
and tcc doesn't support C11.

Next I tried using tcc on a small part of my larger current
project. That test involves compiling one .c file to produce a
.o file, and linking with several other .o files to produce an
executable, and running the executable. The .c file being
compiled uses C99 and doesn't need C11.

The first thing that came up is tcc doesn't support all of
C99. There are some C99 features that tcc just doesn't
understand. In this case the infringements were minor so I
edited the source to work around the missing features.

The second thing to come up is some language incompatibilities.
There are language features that tcc understands, sort of,
but implements them in a way that didn't work with my source
code. To be fair, a case could be made that what tcc does
conforms to the C standard. However, the code I had before
works fine with gcc and clang, and doesn't with tcc. Here
again the changes needed were minor so I edited the source
to work around the problem.

The third thing to come up was the link step. Compiling the
one .c file with tcc -- and there are three other .o files
produced using gcc -- implicated the link step, which needed
to be done with tcc to avoid some undefined symbols. That
kind of surprised me; I'm used to being able to mix gcc
object files and clang object files with no difficulty,
so having the link step fail caught me off guard.

After taking care of all that the build did manage to produce an
executable, which appears to have run successfully.

After doing a trial run with the produced executable, I looked at
the tcc man page. As best I can tell, tcc simply silently
ignores the -fPIC option. (I didn't test that, I only read what
the tcc man page says.) That project absolutely relies on -fPIC,
so if tcc doesn't support it that's a deal breaker.

Not offering any conclusion. Just reporting my experience.

I tried tcc too.

1. It is easy to download. It does not need installation apart from
unzip.

I installed tcc on linux by using apt-get. Worked with no problem.

2. It is very fast. Even when used from makefile, which is not an
optimal mode of use, in my tests more than 3 times faster than MSVC in non-parallel build and more that twice faster in parallel build on
quad-core CPU. And that on project that spends unproportionally long
time in link. I am ready to believe that on more typical projects
(i.e. more compile time, less link time) the difference would be over
5x.
For the record, on this project 'gcc -O2' was ~1.7x slower than 'MSVC
-O2' and 'gcc -O0' was ~1.1x slower than 'MSVC -O2'; the later
difference probably because somewhat faster compilation by 'gcc -O0' was outdone by much slower link.

3. Exe is slow, but not slower than gcc -O0. About the same. In this particular test it meant ~2.5 times slower than optimized gcc or MSVC
binary.

I didn't measure the speed either of the compiler or the
executable. Apparently tcc doesn't understand -S to produce
assembly.

4. In this particular project I encountered few inconvenient incompatibilities:
4.1. no support for %zd and %zu. May be, Linux version is better in that regard?

I tried %zu in tcc on linux and it worked fine.

4.2. Code like below does not compile. I don't know whether it is legal
'C' or not,
but gcc, clang and MSVC compilers accept it o.k.
label:int bar;

Putting a label on a declaration is not supported in either C99
or C11. Maybe those other compilers are using a later version of
C or compiler extensions. Did you use a -std=c?? option, along
with -pedantic? I used -std=c99 -pedantic. tcc accepts -std=c11
but it seems to make no difference to what is accepted.

4.3. c11/c17 things that are supported even by MSVC, which is generally
does not claim full C11 support:
_Alignof()

Support issues that came up in my tests:

1. tcc doesn't understand _Generic at all. That is in keeping
with tcc claiming to be for C99, since _Generic was added
in C11.

2. tcc doesn't understand the simplest form of variably
modified types, such as

int foo( int n, unsigned v[n] );

3. A tcc header for <stdarg.h> does give a macro definition
for va_end(), but it is not as robust as one would like.

It's close to advertised, i.e. it is not C17, but has few features of
C17.

I didn't make any effort to do exhaustive testing. I simply
grabbed some C source files I had lying around and tried to
compile (and later link) them with tcc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 01 Jul 2024 14:48:30 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Michael S <already5chosen@yahoo.com> writes:
[...]

I tried tcc too.

1. It is easy to download. It does not need installation apart from
unzip.

So you're on Windows.

[...]

4. In this particular project I encountered few inconvenient incompatibilities:
4.1. no support for %zd and %zu. May be, Linux version is better in
that regard?

%zd and %zu are supported by the runtime library, not by the compiler.
It's likely that tcc is configured to use something like msvcrt.dll,
which typically doesn't support C99 features.

I think, bart said that tcc is self-contained. I interpreted is like
containing C RTL. Obviously, my interpretation of bart's statement was
wrong and in reality tcc relies on external RTL.
Microsoft's DLLs support majority of C99 format specifiers for quite
long time. I am certain that %zd is supported by DLL supplied with
VS2017, but would guess that it was supported since VS2015, when they
shipped VCRUNTIME140.DLL for the first time. So either 7 or 9 years.
It would be nice if tcc was able to use this newer more compatible,
while sometimes slower, stuff.

4.2. Code like below does not compile. I don't know whether it is
legal 'C' or not,
but gcc, clang and MSVC compilers accept it o.k.
label:int bar;

That's a syntax error in versions of C up to and including C17. C23
allows labels on declarations.

(Incidentally, the N3220 draft says that labels can be applied to
either statements or declarations, but the grammar doesn't seem to
reflect that.)

Now I paid attention that my statement above is incorrect: clang does
*not* accept it.
gcc accepts it, for all supported standards, but with -Wpedantic
it issues the warning for all standards except c2x.
MSVC (17 and 19, but not 13) accepts it and issues no warning even with
maximal warning level.

clang and tcc are right. I find no advantages in this sort of rightness.

4.3. c11/c17 things that are supported even by MSVC, which is
generally does not claim full C11 support:
_Alignof()

It's close to advertised, i.e. it is not C17, but has few features
of C17.

tcc is not advertised to support C17. According to <https://bellard.org/tcc/>, "TCC is heading torward full ISOC99
compliance."

I didn't say that they advertise C17. However in practice they do
support few C11/C17 features. So why not _Alignof() ?
Considering that tcc already supports old Gnu __alignof__ extension,
adding support for _Alignof() would be very easy for them.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/07/2024 09:54, Michael S wrote:

On Mon, 01 Jul 2024 14:48:30 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Michael S <already5chosen@yahoo.com> writes:
[...]

I tried tcc too.

1. It is easy to download. It does not need installation apart from
unzip.

So you're on Windows.

[...]

4. In this particular project I encountered few inconvenient
incompatibilities:
4.1. no support for %zd and %zu. May be, Linux version is better in
that regard?

%zd and %zu are supported by the runtime library, not by the compiler.
It's likely that tcc is configured to use something like msvcrt.dll,
which typically doesn't support C99 features.

I think, bart said that tcc is self-contained. I interpreted is like containing C RTL. Obviously, my interpretation of bart's statement was
wrong and in reality tcc relies on external RTL.

Tcc is partly self-contained in that it turns .c files into binaries
(.exe and .dll) without any external tools.

tcc itself exists as either one .exe file or .exe/.dll (to allow
embedding). It also has a set of system headers. Plus it has some .a
libraries. About 100 files altogether.

My older 'bcc' compiler was a lot more self-contained in that a single
.exe could generate .exe/.dll, and included its system headers. One file altogether (the newer 'mcc' is 2-3 files; it uses a discrete assembler,
and windows.h is a separate file).

Both make use of msvcrt.dll. I don't consider it a dependency since it
has always been part of Windows. (I first starting using it in 1990s,
from my other language, before I knew much about C, as it had a simpler
file API than Windows.)

Lots of other applications use it too. Including older gcc binaries and applications compiled with those.

On Windows 11, probably 10 too, msvcrt.dll's printf routines support
%zu, and so does Tcc.

tcc is not advertised to support C17. According to
<https://bellard.org/tcc/>, "TCC is heading torward full ISOC99
compliance."

I didn't say that they advertise C17. However in practice they do
support few C11/C17 features. So why not _Alignof() ?
Considering that tcc already supports old Gnu __alignof__ extension,
adding support for _Alignof() would be very easy for them.

_Generics is a very easy feature to implement (I did it in about 40
lines). Probably tcc could have it too with little trouble. Maybe
somebody thought they should stick to C99 compliance rather than pick
and choose the easier features of later standards.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2 Jul 2024 12:22:53 +0100
bart <bc@freeuk.com> wrote:

Both make use of msvcrt.dll. I don't consider it a dependency since
it has always been part of Windows. (I first starting using it in
1990s, from my other language, before I knew much about C, as it had
a simpler file API than Windows.)

Lots of other applications use it too. Including older gcc binaries
and applications compiled with those.

On Windows 11, probably 10 too, msvcrt.dll's printf routines support
%zu, and so does Tcc.

Not really.
DLL that supports newer feature has different name - VCRUNTIME140.dll
And choice of DLL version is not directly related to the version of
Windows.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Mon, 01 Jul 2024 14:48:30 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Michael S <already5chosen@yahoo.com> writes:
[...]

4.2. Code like below does not compile. I don't know whether it is
legal 'C' or not,
but gcc, clang and MSVC compilers accept it o.k.
label:int bar;

That's a syntax error in versions of C up to and including C17. C23
allows labels on declarations. [...]

Now I paid attention that my statement above is incorrect: clang does
*not* accept it.
gcc accepts it, for all supported standards, but with -Wpedantic
it issues the warning for all standards except c2x.
MSVC (17 and 19, but not 13) accepts it and issues no warning even with maximal warning level.

clang and tcc are right. I find no advantages in this sort of rightness.

Is your objection to a diagnostic message being issued, or is
your objection to the construct causing the compilation to fail?

I would call what the more recent MSVC versions do as being
*wrong*. The C standard requires a diagnostic.

I would not call what clang and tcc do as being right. Their
behavior conforms to the C standard, but giving an unavoidable
error is kind of obnoxious.

The reported behavior for gcc -pedantic is okay. It would be
nice if there were a separate option to allow the non-standard
labels to be accepted without giving a warning. Also it would
be better if -std=cNN implied -pedantic (presumably with a way
to change that, selectively if possible); historically that
choice might have been okay, but for at least the last 15 years
it has been a disservice to the C community. I should note
specifically that it is -pedantic that should be implied, and
not -pedantic-error.

More generally, the default behavior for any non-conforming but
often used construct should be a warning, not an error (unless of
course -Werror has been specified). I understand the motivation
to give an error in the case of a syntax violation, but forcing
any syntax violation to be an error is still a poor choice, not
just for the compiler but also for the C community generally.

Just my opinions, in case that needs saying.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bart <bc@freeuk.com> writes:

On 02/07/2024 09:54, Michael S wrote:

On Mon, 01 Jul 2024 14:48:30 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

tcc is not advertised to support C17. According to
<https://bellard.org/tcc/>, "TCC is heading torward full ISOC99
compliance."

I didn't say that they advertise C17. However in practice they do
support few C11/C17 features. So why not _Alignof() ?
Considering that tcc already supports old Gnu __alignof__ extension,
adding support for _Alignof() would be very easy for them.

_Generics is a very easy feature to implement (I did it in about 40
lines). Probably tcc could have it too with little trouble.

The key point is that tcc does NOT have it. Whether it
easily could or not is irrelevant.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

On 01/07/2024 22:48, Keith Thompson wrote:

%zd and %zu are supported by the runtime library, not by the compiler.
It's likely that tcc is configured to use something like msvcrt.dll,
which typically doesn't support C99 features.

But that's what you get if you use size_t. Code breaks.

No, it doesn't. Thousands of programmers use size_t
every day without any code breakage, and have for the
last three decades or so.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 02/07/2024 14:27, Michael S wrote:

On Tue, 2 Jul 2024 12:22:53 +0100
bart <bc@freeuk.com> wrote:

Both make use of msvcrt.dll. I don't consider it a dependency since
it has always been part of Windows. (I first starting using it in
1990s, from my other language, before I knew much about C, as it had
a simpler file API than Windows.)

Lots of other applications use it too. Including older gcc binaries
and applications compiled with those.

On Windows 11, probably 10 too, msvcrt.dll's printf routines support
%zu, and so does Tcc.

Not really.
DLL that supports newer feature has different name - VCRUNTIME140.dll
And choice of DLL version is not directly related to the version of
Windows.

Well, both tcc and mcc (my product) import msvcrt, not that runtime
file, and printf/zu works.

You can test it directly using the program below if you like.

If you think that the OS craftily substitutues vcruntime140.dll in place
of msvcrt.dll, then copy "c:\windows\system32\msvcrt.dll" to "fred.dll",
to a folder where it can be found. Then change "msvcrt" beflow to "fred".

If %zu it doesn't work, then maybe your copy is old.

---------------------------
#include <windows.h>
#include <stdlib.h>

int main(void) {
int (*PRINTF)(const char*, ...);
HINSTANCE libinst;

libinst=LoadLibrary("msvcrt");
if (libinst==NULL) exit(1);

PRINTF=GetProcAddress(libinst, "printf");
if (PRINTF==NULL) exit(1);

PRINTF("sizeof void* = %zu\n", sizeof(void*));
}
---------------------------

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

On 01/07/2024 22:48, Keith Thompson wrote:

...

%zd and %zu are supported by the runtime library, not by the compiler.
It's likely that tcc is configured to use something like msvcrt.dll,
which typically doesn't support C99 features.

But that's what you get if you use size_t. Code breaks.

No, code does not break if you use size_t.

Baby X doesn't expose any size_ts in its API, so code written for Baby X should work fine under tcc. Code written for other toolkits will fail if at any time you format a size_t for user display.

size_t was widely used prior to C99 and the introduction of %zu.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2 Jul 2024 15:18:10 +0100
bart <bc@freeuk.com> wrote:

On 02/07/2024 14:27, Michael S wrote:

On Tue, 2 Jul 2024 12:22:53 +0100
bart <bc@freeuk.com> wrote:

Both make use of msvcrt.dll. I don't consider it a dependency since
it has always been part of Windows. (I first starting using it in
1990s, from my other language, before I knew much about C, as it
had a simpler file API than Windows.)

Lots of other applications use it too. Including older gcc binaries
and applications compiled with those.

On Windows 11, probably 10 too, msvcrt.dll's printf routines
support %zu, and so does Tcc.

Not really.
DLL that supports newer feature has different name -
VCRUNTIME140.dll And choice of DLL version is not directly related
to the version of Windows.

Well, both tcc and mcc (my product) import msvcrt, not that runtime
file, and printf/zu works.

You can test it directly using the program below if you like.

If you think that the OS craftily substitutues vcruntime140.dll in
place of msvcrt.dll, then copy "c:\windows\system32\msvcrt.dll" to "fred.dll", to a folder where it can be found. Then change "msvcrt"
beflow to "fred".

If %zu it doesn't work, then maybe your copy is old.

---------------------------
#include <windows.h>
#include <stdlib.h>

int main(void) {
int (*PRINTF)(const char*, ...);
HINSTANCE libinst;

libinst=LoadLibrary("msvcrt");
if (libinst==NULL) exit(1);

PRINTF=GetProcAddress(libinst, "printf");
if (PRINTF==NULL) exit(1);

PRINTF("sizeof void* = %zu\n", sizeof(void*));
}
---------------------------

I am not logged into Win10/11 right now, so tried on Ws2016 witch is
mostly the same as early Win10. It didn't work.
Then I went and tested on Ws2019 which is similar to midlife Windows 10.
It works.
I didn't [yet] try to mess with DLLs in system folder but I looked at
versions.
on Ws2016 - 7.0.14393.2457
on Ws2019 - 7.0.17763.475

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Mon, 1 Jul 2024 20:09:24 +0300
Michael S <already5chosen@yahoo.com> wrote:

As far as I am concerned, the most intriguing feature of tcc is "Memory
and Bound checks". Unfortunately, I was not able to make it work. It
keeps telling me "segmentation error" at first attempt to dereference
argv. Is this feature Linux-only or 32-bit only or some other type
of "only" ?

The documentation says it should work on x86_64 in Windows.

Can you post the code so we can compare. With this little program

#include <stdio.h>

void f(int *a, int n)
{
printf("a[%d] == %d\n", n, a[n]);
}

int main(int argc, char **argv)
{
for (int i = 0; i <= argc; i++)
if (argv[i])
printf("argv[%d] == %s\n", i, argv[i]);
else printf("argv[%d] is a null pointer\n", i);
int a[3];
f(a, 3);
}

I get this output:

$ ./a.out 1
argv[0] == ./a.out
argv[1] == 1
argv[2] is a null pointer
004021b9 : at ???: BCHECK: 0x7ffca6719404 is outside of the region
t.c:5: by f
t.c:15: by main
t.c:5: at f: RUNTIME ERROR: invalid memory access
t.c:15: by main

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 1 Jul 2024 20:09:24 +0300
Michael S <already5chosen@yahoo.com> wrote:

As far as I am concerned, the most intriguing feature of tcc is "Memory
and Bound checks". Unfortunately, I was not able to make it work. It
keeps telling me "segmentation error" at first attempt to dereference
argv. Is this feature Linux-only or 32-bit only or some other type
of "only" ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 02 Jul 2024 16:32:23 +0100
Ben Bacarisse <ben@bsb.me.uk> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Mon, 1 Jul 2024 20:09:24 +0300
Michael S <already5chosen@yahoo.com> wrote:

As far as I am concerned, the most intriguing feature of tcc is
"Memory and Bound checks". Unfortunately, I was not able to make it
work. It keeps telling me "segmentation error" at first attempt to dereference argv. Is this feature Linux-only or 32-bit only or some
other type of "only" ?

The documentation says it should work on x86_64 in Windows.

Can you post the code so we can compare. With this little program

#include <stdio.h>

void f(int *a, int n)
{
printf("a[%d] == %d\n", n, a[n]);
}

int main(int argc, char **argv)
{
for (int i = 0; i <= argc; i++)
if (argv[i])
printf("argv[%d] == %s\n", i, argv[i]);
else printf("argv[%d] is a null pointer\n", i);
int a[3];
f(a, 3);
}

I get this output:

$ ./a.out 1
argv[0] == ./a.out
argv[1] == 1
argv[2] is a null pointer
004021b9 : at ???: BCHECK: 0x7ffca6719404 is outside of the region
t.c:5: by f
t.c:15: by main
t.c:5: at f: RUNTIME ERROR: invalid memory access
t.c:15: by main

I got plain "Segmentation fault".

I it gets me "Segmentation fault" on something as simple as:

#include <stdio.h>
int main(int argc, char **argv)
{
printf("%p\n", argv[0]);
return 0;
}

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/2/24 04:54, Michael S wrote:

On Mon, 01 Jul 2024 14:48:30 -0700
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

...

tcc is not advertised to support C17. According to
<https://bellard.org/tcc/>, "TCC is heading torward full ISOC99
compliance."

I didn't say that they advertise C17. However in practice they do
support few C11/C17 features. So why not _Alignof() ?
Considering that tcc already supports old Gnu __alignof__ extension,
adding support for _Alignof() would be very easy for them.

They're still working on C99 compliance. If I had any interest in using
tcc (which I don't), I'd want them to finish C99 before going on to
other things, no matter how easy those other things are. Exception: some features added in C99 were made optional in later standards. Unless tcc
already supports those features, they don't need to, and even if they do
plan to, they should make implementing them a low priority compared to
getting the rest of C99 implemented.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S <already5chosen@yahoo.com> writes:

On Tue, 02 Jul 2024 16:32:23 +0100
Ben Bacarisse <ben@bsb.me.uk> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Mon, 1 Jul 2024 20:09:24 +0300
Michael S <already5chosen@yahoo.com> wrote:

As far as I am concerned, the most intriguing feature of tcc is
"Memory and Bound checks". Unfortunately, I was not able to make it
work. It keeps telling me "segmentation error" at first attempt to
dereference argv. Is this feature Linux-only or 32-bit only or some
other type of "only" ?

The documentation says it should work on x86_64 in Windows.

Can you post the code so we can compare. With this little program

#include <stdio.h>

void f(int *a, int n)
{
printf("a[%d] == %d\n", n, a[n]);
}

int main(int argc, char **argv)
{
for (int i = 0; i <= argc; i++)
if (argv[i])
printf("argv[%d] == %s\n", i, argv[i]);
else printf("argv[%d] is a null pointer\n", i);
int a[3];
f(a, 3);
}

I get this output:

$ ./a.out 1
argv[0] == ./a.out
argv[1] == 1
argv[2] is a null pointer
004021b9 : at ???: BCHECK: 0x7ffca6719404 is outside of the region
t.c:5: by f
t.c:15: by main
t.c:5: at f: RUNTIME ERROR: invalid memory access
t.c:15: by main

I got plain "Segmentation fault".

I it gets me "Segmentation fault" on something as simple as:

#include <stdio.h>
int main(int argc, char **argv)
{
printf("%p\n", argv[0]);
return 0;
}

Ah. That looks like a plain "not working" then. (Presumably you get a reasonable-looking pointer without the -b option). What version of tcc?

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 02 Jul 2024 17:12:47 +0100
Ben Bacarisse <ben@bsb.me.uk> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Tue, 02 Jul 2024 16:32:23 +0100
Ben Bacarisse <ben@bsb.me.uk> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Mon, 1 Jul 2024 20:09:24 +0300
Michael S <already5chosen@yahoo.com> wrote:

As far as I am concerned, the most intriguing feature of tcc is
"Memory and Bound checks". Unfortunately, I was not able to make
it work. It keeps telling me "segmentation error" at first
attempt to dereference argv. Is this feature Linux-only or
32-bit only or some other type of "only" ?

The documentation says it should work on x86_64 in Windows.

Can you post the code so we can compare. With this little program

#include <stdio.h>

void f(int *a, int n)
{
printf("a[%d] == %d\n", n, a[n]);
}

int main(int argc, char **argv)
{
for (int i = 0; i <= argc; i++)
if (argv[i])
printf("argv[%d] == %s\n", i, argv[i]);
else printf("argv[%d] is a null pointer\n", i);
int a[3];
f(a, 3);
}

I get this output:

$ ./a.out 1
argv[0] == ./a.out
argv[1] == 1
argv[2] is a null pointer
004021b9 : at ???: BCHECK: 0x7ffca6719404 is outside of the region
t.c:5: by f
t.c:15: by main
t.c:5: at f: RUNTIME ERROR: invalid memory access
t.c:15: by main

I got plain "Segmentation fault".

I it gets me "Segmentation fault" on something as simple as:

#include <stdio.h>
int main(int argc, char **argv)
{
printf("%p\n", argv[0]);
return 0;
}

Ah. That looks like a plain "not working" then. (Presumably you get
a reasonable-looking pointer without the -b option). What version of
tcc?

0.9.27

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2 Jul 2024 16:27:04 +0300
Michael S <already5chosen@yahoo.com> wrote:

On Tue, 2 Jul 2024 12:22:53 +0100
bart <bc@freeuk.com> wrote:

Both make use of msvcrt.dll. I don't consider it a dependency since
it has always been part of Windows. (I first starting using it in
1990s, from my other language, before I knew much about C, as it had
a simpler file API than Windows.)

Lots of other applications use it too. Including older gcc binaries
and applications compiled with those.

On Windows 11, probably 10 too, msvcrt.dll's printf routines
support %zu, and so does Tcc.

Not really.
DLL that supports newer feature has different name - VCRUNTIME140.dll
And choice of DLL version is not directly related to the version of
Windows.

I tried to use new Microsoft library from tcc. It is not hard, but not
quite as simple as repacing the name of DLL.
Here is step-by-step example with dynamic load of DLL (most of the
underscored nonsense that I copied from MS's stdio.h likely
non-necessary):


#include <windows.h>
#include <stdarg.h>
#include <stdio.h>

FILE* __cdecl (*__acrt_iob_func)(unsigned _Ix);
int __cdecl (*__stdio_common_vfprintf)(
unsigned __int64 _Options,
FILE* _Stream,
char const* _Format,
_locale_t _Locale,
va_list _ArgList
);

_Bool init(void)
{
HINSTANCE libinst=LoadLibrary("ucrtbase");
if (!libinst) {
printf("LoadLibrary() Fail. Error %u.\n", GetLastError());
return 0;
}
FARPROC l__acrt_iob_func = GetProcAddress(libinst, "__acrt_iob_func");
if (!l__acrt_iob_func) {
printf("GetProcAddress(__acrt_iob_func) Fail. Error %u.\n", GetLastError()); return 0;
}
FARPROC l__stdio_common_vfprintf = GetProcAddress(libinst, "__stdio_common_vfprintf"); if (!l__stdio_common_vfprintf) {
printf("GetProcAddress(__stdio_common_vfprintf) Fail. Error %u.\n", GetLastError()); return 0;
}
__acrt_iob_func = l__acrt_iob_func;
__stdio_common_vfprintf = l__stdio_common_vfprintf;
return 1;
}

__declspec(noinline) __inline unsigned __int64* __cdecl __local_stdio_printf_options(void) {
static unsigned __int64 _OptionsStorage;
return &_OptionsStorage;
}

__inline int __cdecl _vfprintf_l(
FILE* const _Stream,
char const* const _Format,
_locale_t const _Locale,
va_list _ArgList)
{
return __stdio_common_vfprintf((*__local_stdio_printf_options()),
_Stream, _Format, _Locale, _ArgList); }

__inline int ucrt_printf(char const* const format, ...)
{
va_list argList;
va_start(argList, format);
int result = _vfprintf_l(__acrt_iob_func(1), format, 0, argList);
va_end(args);
return result;
}

int main(void) {
if (init())
ucrt_printf("sizeof void* = %zu\n", sizeof(void*));
return 0;
}


If tcc is still maintained and assuming that licenses are compatible,
and assuming that a little bit of bloat is acceptable, tcc maintainer
can copy necessary stubs from mingw project.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 1 Jul 2024 20:09:24 +0300
Michael S <already5chosen@yahoo.com> wrote:

I tried tcc too.

Plenty of C99 math stuff unavailable with tcc on Windows.
E.g. all hyperbolic functions, erf(), exp2(), everything related FP environment, fma(), ilogb(), lgamma(), log2(), logb(), lrint(),
lround(), nearbyint(), nextafter(), norm() etc... Probably, 95% of the
missing functions can be made available by simple linking vs
msvcr120.dll (instead of msvcrt.dll). I don't know if the two are fully compatible, but for tcc purposes they are compatible enough. For another
5% they would have to do bigger and more laborious step, i.e. switch to
UCRT.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 2 Jul 2024 18:17:50 +0300
Michael S <already5chosen@yahoo.com> wrote:

On Mon, 1 Jul 2024 20:09:24 +0300
Michael S <already5chosen@yahoo.com> wrote:

As far as I am concerned, the most intriguing feature of tcc is
"Memory and Bound checks". Unfortunately, I was not able to make it
work. It keeps telling me "segmentation error" at first attempt to dereference argv. Is this feature Linux-only or 32-bit only or some
other type of "only" ?

I tested bound checking on Linux. Here it does not crash. Compilation
is not much slower than without bound checks. Result speed in my tests
was 6-7 times slower than tcc without checks or ~20 times slower than
optimized gcc. I have no idea how this speed impact compares with other
similar tools.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)