Bart <bc@freeuk.com> writes:
> On 30/07/2021 19:12, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> OK. But gcc and tcc are products that you expect to make the necessary
>>> arrangements for ensuring they your program can call a C standard
>>> function called "printf".
>> No, they are not. They are components that can be combined with
>> other
>> components to create a C implementation. Getting that right is the
>> responsibility of whoever puts together the implementation.
>> You've written compilers, so you should know all this stuff.
>> If someone puts together an implementation that uses gcc as its
>> compiler
>> and the obsolete MSVCRT.DLL as its runtime library, the result is a
>> non-conforming implementation.
>
> Well, /I/ didn't tell gcc which runtime to choose. Or is that now my
> responsibility?

Whose responsibility do you think it is?

You installed gcc on your Windows system *somehow*. The gcc project
itself does not provide installers for Windows. You installed
something from some third party, and that installer is responsible
for coordinating the various components of the implementation,
of which the compiler is just one.

If you're satisfied with the way your system is working now, then
neither you nor anyone else is responsible for changing it.

An implementation that didn't support "%zu" would be a problem *for
me*. If I were using such an implementation, I would look for ways to
fix or replace it. You will of course do what you want.

A great deal of this thread started when you said you wanted to avoid
"%zu", and I went out of my way not to ask why. (Admittedly I was being
a bit snarky.) I nevertheless have a better understanding now of why
you want to avoid "%zu", and I'm not quite sure why we're still talking
about it.

> I now know that mine will default to Windows' msvcrt.dll unless I
> specifically tell it to use libucrt.a. Why the default isn't the other
> way around is not something I'm surprised at any more; there are much
> worse defaults, and more dangerous.

You realize that has to do with C implementations on Windows, not with C
the language.

>> My experience with Windows C implementations is fairly narrow, but I get
>> the impression that most Windows C programmers don't need to worry about
>> "%zu" because they use implementations that support it. If it's a
>> widespread problem (which is possible), I haven't heard about it other
>> than from you.
>
> Download tcc, which is now a well-respected C99 implementation, and
> blazingly fast, and let me know if it supports "zu" out-of-the-box,
> and if not, whether there is a way to make it do so.

I might try installing tcc on Windows later. Of course whether it
supports "%zu" or not depends on what runtime library implementation
it's configured to use. I see the web site has several zip files. I
see that at least one of them has some references to msvcrt, but I don't
know the details.

> If you're on Windows, try this:
>
> * Download the program:
>
> https://github.com/sal55/langs/blob/master/qq.exe (about 640KB)

No, I'm not going to download and run a binary executable from some
random GitHub repo.

[snip]

> I'd be interested in whether any Windows executable produced by your
> gcc also imports msvcrt.dll, which looks like this using my dump
> program:
[snip]

On Unix/Linux systems, the "ldd" command shows a list of the shared
objects that an executable depends on. The version that runs on Cygwin
does the same thing, and shows a list of DLLs. Here's what I get when I
compile a simple "hello" program using the default gcc on Cygwin (yes,
I'm aware that this is likely not to be typical of how a non-Cygwin gcc
installation would work):

$ gcc hello.c -o hello.exe
$ file hello.exe
hello.exe: PE32+ executable (console) x86-64, for MS Windows
$ ldd hello.exe
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe5db80000)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ffe5c2c0000)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ffe5b8a0000)
cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
$

Nothing I've tried gives me an executable that refers to msvcrt.dll.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 30/07/2021 19:17, Keith Thompson wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Bart <bc@freeuk.com> writes:
>>>> On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:
>>>
>>>>> No, I don't, because I read the documentation.
>>>>
>>>> Are you serious? Just gcc.info is 1000 pages of options.
>>>
>>> RTFM. And, much as I dislike the GNU info utility UI, the
>>> data is well organized and fairly complete.
>>>
>>>
>>>> I don't even know what gcc bundle Keith might have. Also he doesn't have
>>>> tcc so he cannot say what that does or doesn't do.
>>>
>>> I believe he mentioned using cygwin gcc, which comes with glibc.
>> Cygwin gcc uses newlib, not glibc.
>>
>
> If you're using gcc via Cygwin, then all bets are off.
>
> It's not using gcc as a native Windows application, actually I don't
> even know if you still end up with EXE files rather than ELF, and I
> don't know what libraries will be used.
>
> Cygwin is an attempt to bring elements of Linux to Windows (along with
> MSYS2 and WSL). I would not count it as directly running a C compiler
> on Windows, and you can't really compare behaviour.
>
> Like saying that your gcc (ie. running under Cygwin) works; mine
> doesn't, therefore I must be doing something wrong.

I don't recall saying that. I said that gcc under Cygwin works as a
data point.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 30/07/2021 21:10, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 30/07/2021 19:17, Keith Thompson wrote:
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>> Bart <bc@freeuk.com> writes:
>>> If you're using gcc via Cygwin, then all bets are off.
>>>
>>> It's not using gcc as a native Windows application, actually I don't
>>> even know if you still end up with EXE files rather than ELF, and I
>>> don't know what libraries will be used.
>>>
>>> Cygwin is an attempt to bring elements of Linux to Windows (along with
>>> MSYS2 and WSL). I would not count it as directly running a C compiler on
>>> Windows, and you can't really compare behaviour.
>>>
>> So use WSL instead of cygwin. You can download it from the
>> windows store, in multiple flavors. Fully supported by
>> Microsoft.
>
> This is actually pretty crazy, suggesting buying a new PC with Windows
> 10, switching OS pretty much, to solve an utterly insignificant
> non-problem.

Nobody suggested buying a new PC.

If your current PC isn't powerful enough to support WSL (the only reason
I can think of for you to bring it up), then you can either get a new
PC or not use WSL. I have no opinion on which you should do.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:
> On 30/07/2021 20:01, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> But this is all getting away from the point you're trying to make,
>>> which is that gcc has no hand at all it in providing a 'printf'
>>> function for my C programs.
>>>
>>> You're wrong.
>>
>> No, he's right.
>>
>>> Further, if I try and compile this program:
>>>
>>> extern int printf(long long,...);
>>>
>>> int main(void) {
>>> printf((long long)"Hello, World!\n");
>>> }
>>>
>>> gcc complains that my printf conflicts with the built-in printf; so it
>>> knows perfectly well what it is. It will even tell me if I get the
>>> format codes wrong!
>>
>> gcc's warning message for that is:
>>
>> warning: conflicting types for built-in function ‘printf’; expected
>> ‘int(const char *, ...)’ [-Wbuiltin-declaration-mismatch]
>>
>> The use of the term "built-in" is slightly misleading. The printf
>> function is not built into the compiler. (Conceivably a compiler could
>> provide a built-in printf implementation, but as far as I know none do).
>
> It does say "builtin /declaration/ mismatch" - the "printf" function is
> not a builtin in gcc, but the declaration is. (As you mentioned, it can
> have that since the C standard specifies the declaration.)

The warning message and the option name contain different information.

And both omit some relevant information so they don't turn into novels.

Strictly speaking, the declaration of printf is in the <stdio.h> header,
which is not provided by gcc. What's built into gcc is information
about the standard's requirements for printf. That includes both how
it's declared and the semantics of the format string (used to generate
warnings when the format string is a string literal).

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
[...]
> For the record, my current 'gcc' that I use on plain Windows is this
> product:
>
> https://jmeubank.github.io/tdm-gcc/download/

https://jmeubank.github.io/tdm-gcc/about/ :

TDM-GCC is a compiler suite for Windows.

It combines the most recent stable release of the GCC compiler, a
few patches for Windows-friendliness, and the free and open-source
MinGW.org or MinGW-w64 runtime APIs, to create a more lightweight
open-source alternative to Microsoft’s compiler and platform SDK.

TDM-GCC is not a compiler.

TDM-GCC is not gcc.

TDM-GCC is not produced or maintained by the gcc project.

TDM-GCC is a software package that combines a compiler (gcc) and other
components (MinGW runtime libraries, probably other things) into a C
implementation.

Other software packages might combine the gcc compiler with other
runtime library implementations. For example, there are packages that
combine the gcc compiler with Microsoft's runtime library.

If any of the above is inaccurate, Bart, I encourage you to correct me.

You seem to imply that TDM-GCC gives you an implementation that by
default uses the obsolete MSVCRT.DLL, and therefore does not support
"%zu". I find that at least mildly surprising. I might install it
myself over the weekend to see what's going on.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 30/07/2021 22:44, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 30/07/2021 19:17, Keith Thompson wrote:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:
>>>>
>>>>>> No, I don't, because I read the documentation.
>>>>>
>>>>> Are you serious? Just gcc.info is 1000 pages of options.
>>>>
>>>> RTFM. And, much as I dislike the GNU info utility UI, the
>>>> data is well organized and fairly complete.
>>>>
>>>>
>>>>> I don't even know what gcc bundle Keith might have. Also he doesn't have
>>>>> tcc so he cannot say what that does or doesn't do.
>>>>
>>>> I believe he mentioned using cygwin gcc, which comes with glibc.
>>> Cygwin gcc uses newlib, not glibc.
>>>
>>
>> If you're using gcc via Cygwin, then all bets are off.
>>
>> It's not using gcc as a native Windows application, actually I don't
>> even know if you still end up with EXE files rather than ELF, and I
>> don't know what libraries will be used.
>>
>> Cygwin is an attempt to bring elements of Linux to Windows (along with
>> MSYS2 and WSL). I would not count it as directly running a C compiler
>> on Windows, and you can't really compare behaviour.
>>
>> Like saying that your gcc (ie. running under Cygwin) works; mine
>> doesn't, therefore I must be doing something wrong.
>
> I don't recall saying that. I said that gcc under Cygwin works as a
> data point.
>

But why does it have to run under Cygwin? It's clearly trying to
recreate some aspects of Linux under Windows. Therefore you can't
compare that version of gcc with mine.

For a fair comparison, install what I have, and run it as I do. THEN
tell me I'm doing something wrong.

Most here seem to be telling me to ditch Windows, which is effectively
what using WSL is. (My main PC is Windows 7; the laptop with W10 is too
underpowered for WSL; but I don't care anyway.)

I don't like that; imagine if I told you lot to ditch Unix after a
lifetime of working with it, because one tiny thing works better on Windows.

On 30/07/2021 23:34, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> For the record, my current 'gcc' that I use on plain Windows is this
>> product:
>>
>> https://jmeubank.github.io/tdm-gcc/download/
>
> https://jmeubank.github.io/tdm-gcc/about/ :
>
> TDM-GCC is a compiler suite for Windows.
>
> It combines the most recent stable release of the GCC compiler, a
> few patches for Windows-friendliness, and the free and open-source
> MinGW.org or MinGW-w64 runtime APIs, to create a more lightweight
> open-source alternative to Microsoft’s compiler and platform SDK.
>
> TDM-GCC is not a compiler.
>
> TDM-GCC is not gcc.
>
> TDM-GCC is not produced or maintained by the gcc project.
>
> TDM-GCC is a software package that combines a compiler (gcc) and other
> components (MinGW runtime libraries, probably other things) into a C
> implementation.
>
> Other software packages might combine the gcc compiler with other
> runtime library implementations. For example, there are packages that
> combine the gcc compiler with Microsoft's runtime library.
>
> If any of the above is inaccurate, Bart, I encourage you to correct me.
>
> You seem to imply that TDM-GCC gives you an implementation that by
> default uses the obsolete MSVCRT.DLL, and therefore does not support
> "%zu". I find that at least mildly surprising. I might install it
> myself over the weekend to see what's going on.
>

C:\c>type c.c
#include <stdio.h>
int main(void) {
printf("Hello, World! %zu\n",sizeof(void*));
}

C:\c>gcc --version
gcc (tdm64-1) 9.2.0
<snip>

C:\c>gcc c.c

C:\c>a
Hello, World! zu

C:\c>gcc c.c -lucrt

C:\c>a
Hello, World! 8

C:\c>gcc c.c \tdm\x86_64-w64-mingw32\lib\libmsvcrt.a

C:\c>a
Hello, World! zu

C:\c>

Bart <bc@freeuk.com> writes:
> On 30/07/2021 22:44, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 30/07/2021 19:17, Keith Thompson wrote:
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>> On 30/07/2021 17:08, james...@alumni.caltech.edu wrote:
>>>>>
>>>>>>> No, I don't, because I read the documentation.
>>>>>>
>>>>>> Are you serious? Just gcc.info is 1000 pages of options.
>>>>>
>>>>> RTFM. And, much as I dislike the GNU info utility UI, the
>>>>> data is well organized and fairly complete.
>>>>>
>>>>>> I don't even know what gcc bundle Keith might have. Also he doesn't have
>>>>>> tcc so he cannot say what that does or doesn't do.
>>>>>
>>>>> I believe he mentioned using cygwin gcc, which comes with glibc.
>>>> Cygwin gcc uses newlib, not glibc.
>>>
>>> If you're using gcc via Cygwin, then all bets are off.
>>>
>>> It's not using gcc as a native Windows application, actually I don't
>>> even know if you still end up with EXE files rather than ELF, and I
>>> don't know what libraries will be used.
>>>
>>> Cygwin is an attempt to bring elements of Linux to Windows (along with
>>> MSYS2 and WSL). I would not count it as directly running a C compiler
>>> on Windows, and you can't really compare behaviour.
>>>
>>> Like saying that your gcc (ie. running under Cygwin) works; mine
>>> doesn't, therefore I must be doing something wrong.
>> I don't recall saying that. I said that gcc under Cygwin works as a
>> data point.
>
> But why does it have to run under Cygwin? It's clearly trying to
> recreate some aspects of Linux under Windows. Therefore you can't
> compare that version of gcc with mine.

Who says it has to? I use a version of gcc that runs under Cygwin
because I find it convenient. I mentioned its behavior because that was
the information I had.

> For a fair comparison, install what I have, and run it as I do. THEN
> tell me I'm doing something wrong.

When did I tell you you're doing something wrong?

You're apparently using a non-conforming implementation. If you're
happy with that, I have no objection (why would I?). I will, however,
point out that it's non-conforming so that you can make whatever use of
that information you like.

You've made what I believe to be some incorrect statements. I've
replied to them.

> Most here seem to be telling me to ditch Windows, which is effectively
> what using WSL is. (My main PC is Windows 7; the laptop with W10 is
> too underpowered for WSL; but I don't care anyway.)

I haven't seen anyone here tell you to ditch Windows. If the outdated
hardware and software you're using serve your purposes, that's great.

We were discussing Cygwin, and somebody mentioned WSL *as an alternative
to Cygwin*. The person who mentioned WSL had no reason to know whether
your system is capable of supporting it. So don't use Cygwin. Don't
use WSL. Nobody here wants you to. If anybody did want you to, you
could just ignore them.

> I don't like that; imagine if I told you lot to ditch Unix after a
> lifetime of working with it, because one tiny thing works better on
> Windows.

That would be mildly annoying, and I'd probably ignore it.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> wrote:
>
> Further, if I try and compile this program:
>
> extern int printf(long long,...);
>
> int main(void) {
> printf((long long)"Hello, World!\n");
> }
>
> gcc complains that my printf conflicts with the built-in printf; so it
> knows perfectly well what it is. It will even tell me if I get the
> format codes wrong!

You should know how things work (and 'long long' is sign that
you prefer to complain instead of taking advantage of capabilites
of gcc). As a little ilustration that printf is independent from
gcc you can try the following (on Linux, see remarks below about
Windows).

You need two files, first called 'printf.c' second 'ts2a.c'.

---------------------<printf.c start>----------------------

extern int printf(const char *f, ...);

extern int putchar(int c);
#include <stdarg.h>
#include <string.h>
int
printf(const char *f, ...) {
if (!strcmp(f, "%zu\n")) {
va_list ap;
va_start(ap, f);
size_t val = va_arg(ap, size_t);
va_end(ap);
if ((val < 10) && (val >= 0)) {
putchar('0'+val);
putchar('\n');
return 2;
}
}
return 0;
}

---------------------<printf.c end>------------------------

---------------------<ts2a.c start>------------------------
extern int printf(const char *f, ...);

int main(void) {
printf("%zu\n", sizeof(void*));
}

---------------------<ts2a.c end>--------------------------

First compile printf.c:

gcc -Wall -O -c printf.c

Then compile test program:

gcc -Wall -O ts2a.c printf.o -o ts2a

Resulting program uses 'printf' defined in 'printf.c'. Of course,
this is silly implementation handling only single format string,
but using the similar principle one can create full version.
More elegant solution would put new printf (and variations of
printf) in a new library (say 'libmyc'). Linking with 'libmyc'
would give you better version of selected standard function
and allow use of other functions from system library. You can
do equivalent of this on Windows. Sorry, I will not give you
details, I did such things on (more precisly for) Windows
in the past but it you who apparently cares about Windows,
so it is for you to do the homework.

--
Waldek Hebisch

Bart <bc@freeuk.com> writes:
> On 30/07/2021 23:34, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> For the record, my current 'gcc' that I use on plain Windows is this
>>> product:
>>>
>>> https://jmeubank.github.io/tdm-gcc/download/
>> https://jmeubank.github.io/tdm-gcc/about/ :
>> TDM-GCC is a compiler suite for Windows.
>> It combines the most recent stable release of the GCC compiler,
>> a
>> few patches for Windows-friendliness, and the free and open-source
>> MinGW.org or MinGW-w64 runtime APIs, to create a more lightweight
>> open-source alternative to Microsoft’s compiler and platform SDK.
>> TDM-GCC is not a compiler.
>> TDM-GCC is not gcc.
>> TDM-GCC is not produced or maintained by the gcc project.
>> TDM-GCC is a software package that combines a compiler (gcc) and
>> other
>> components (MinGW runtime libraries, probably other things) into a C
>> implementation.
>> Other software packages might combine the gcc compiler with other
>> runtime library implementations. For example, there are packages that
>> combine the gcc compiler with Microsoft's runtime library.
>> If any of the above is inaccurate, Bart, I encourage you to correct
>> me.
>> You seem to imply that TDM-GCC gives you an implementation that by
>> default uses the obsolete MSVCRT.DLL, and therefore does not support
>> "%zu". I find that at least mildly surprising. I might install it
>> myself over the weekend to see what's going on.
>
> C:\c>type c.c
> #include <stdio.h>
> int main(void) {
> printf("Hello, World! %zu\n",sizeof(void*));
> }
>
> C:\c>gcc --version
> gcc (tdm64-1) 9.2.0
> <snip>
>
> C:\c>gcc c.c
>
> C:\c>a
> Hello, World! zu
>
> C:\c>gcc c.c -lucrt
>
> C:\c>a
> Hello, World! 8
>
> C:\c>gcc c.c \tdm\x86_64-w64-mingw32\lib\libmsvcrt.a
>
> C:\c>a
> Hello, World! zu
>
> C:\c>

OK, that demonstrates that TDM-GCC by default does not support "%zu".
It doesn't directly demonstrate that it uses MSVCRT.DLL, but that's
probably the most likely explanation.

Did you want to reply to anything else I wrote? Should I assume that
you agree with the points I made above? (I would greatly appreciate a
direct reply to that last question.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 30/07/2021 22:16, David Brown wrote:
> On 30/07/2021 21:03, Bart wrote:

>> Plus, system DLLs (as I consider msvcrt.dll) are usually not practical
>> to statically link, because only DLLS are available (eg. kernel32.dll).
>>
>
> Regardless of how you consider things, "msvcrt.dll" is not a system DLL.
> And any decent C standard library will be available for static linking.
> (/Real/ system libraries, such as kernel32.dll, are a different matter.)

I first started using msvcrt.dll or equivalent in mid-90s. I didn't use
it from C.

To me it was just another library that came with Windows, with a smaller
and much simpler API. It was also documented as part of the SDK IIRC.

I was hardly even aware then that it was to do with C; as such a
library, it could be used from any language, and itself didn't need to
be implemented in C (the binary clearly wasn't C!).

>> How big would a program be if it incorporated half the Windows API as
>> statically linked code?
>>
>
> For someone who claims to have developed their own languages, compilers,
> linkers and other tools for decades, you are remarkably ignorant of how
> toolchains work.

Why, what's wrong with my question? It is perfectly reasonable.

I might consider bundling RAYLIB with an application for example, by
statically linking (it's some 3MB I think). But not libraries which are
guaranteed to come with the OS.

(Some exceptions such as OpenGL where the OS one may lag behind.)

> Or you are trolling, as some people have suggested.
> Perhaps you have just written in haste, without thinking - everyone
> makes mistakes and occasionally writes something stupid.

OK, now I'm curious; what's the thing that is stupid? Having an opinion
different from yours?

>> You just want to pour more scorn on the efforts of amateur compiler
>> writers.
>>
>
> Given that there are other free C runtime libraries, I don't see any
> good reason for using it when you simply want C coding,

I don't like dependencies. I like that there is just my program, and the
OS. Some third party libraries may necessarily have to be sourced, but
MSVCRT.DLL works perfectly well for the vast majority of my needs.

(From my private language, I only use about 20 C functions anyway, out
of about 1400 in MSVCRT.DLL.

It wouldn't be that hard to eliminate it (I did without it for years).)

without a
> specific need for compatibility with (older) MS tools. It is quite
> possible that MSVCRT.DLL was the best choice in the past - it is not
> now. I can't say I have looked into this in too much detail, since it
> is not an issue that is at all relevant to me or my work. But I could
> point out that at least two people here have shown the use of gcc with C
> libraries that are quite happy with C99 printf. One - Keith - said he
> had no trouble when using Cygwin.

I use Windows. (Imagine someone said they had no problem running my
Windows program under Wine; but Wine isn't Linux)

> Someone else - I forget who - said
> they could just use the "-lucrt" switch to get a working library.

That was me. But it's not a solution (assuming there was a problem in
the first place) as I need to have C code run under bcc and tcc.
Especially tcc, since I have an upcoming project that may need a C
backend (and for some challenging C code), and using any other compiler
would be like hitting a brick wall.

> But let me rephrase. Anyone competent and interested in compiling gcc,
> can take the source code and compile it and package it in whatever way
> they like.

Not interested. Life is too short. My entire compiler builds in 0.2
seconds, but might generate code 50% slower than gcc. That will do me.

>> That is a totally different world from what I do. My product doesn't
>> even HAVE a linker! (Because it doesn't need it; an obsolete concept in
>> my view.)
>>
>
> Yes, but your tools are useless for anyone but you.

Sure. But they are also proof of concept. Want a blazing fast C
compiler? I've done it! (Tcc got there first and better, but I'm not far
behind.)

Do away with object files? I've done it! Do away with a linker? I've
done it! Do away with makefiles? I've done it! Write a whole-program
compiler? I've done it! (But not with C - yet.) A 4-million-line-per
second assembler? I've done it!

So it can all show what is possible. Of little interest in this group
obviously and especially to you because you don't understand that some
of us are interested in developing efficient, minimalist, human-scale
tools, and which might be an inspiration to others.

> gcc (and binutils
> for the linker, assuming that's the linker you are using) are designed
> to be used by vast numbers of people for vast numbers of different
> purposes in vast numbers of different circumstances.
>
> Do you also complain about the size of supermarkets, or the number of
> restaurants in your town, just because you are happy with a cheese
> sandwich for dinner every night?

I would like to cook my own recipes without getting involved in
industrial-scale food production. There's a need for that, obviously,
but I'm simply not interested.

> Look, no one gives a ***** about your private little toy language. No
> one cares. It is useless for anything real.

I would let that go. But actually, I worked in a commercial environment
for 20 years and used exclusively my private languages.

They /were/ useful, and were used for a product that was generating,
then, perhaps $1m a year of business. So I'm not going to be shouted
down by you.

Even if it was the
> greatest invention since sliced bread, no one would use it because it is
> the product of one angry little man whose prime motivation is a bizarre
> and obsessive hatred of C (and C++) and tools for those languages.

This entire subthread is a perfect example of what I hate about it: all
this fuss about a stupid "%zu" format code just to print out a number.

Whose idea was that? And how about /properly/ fixing 'print'?

> This
> is comp.lang.c, where we use and discuss C.

I knew it was a mistake coming back to this newsgroup.

You know, because of the massive negative reaction in this group
(everthing I did was wrong, all my C code was rubbish, I knew nothing
about the language, etc etc) a year ago I burnt most of my bridges with
C, got rid of my C backends; actually you guys put me off the language a
lot more than the language itself.

That was a mistake. A C target is genuinely useful to have. And you
people don't actually own the language. Neither do you write any of the
tools, mostly (some exceptions like JN).

And, you can't actually tell people what they can or can't do (go and
program in WSL; no thanks!).

So I'm resurrecting that C target in a novel, experimental project. I
won't make the mistake of posting code here for you to shoot down. And I
will use whatever compilers I like with the libraries I want and on the
OSes that I choose.

On 31/07/2021 00:33, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>>
>> Further, if I try and compile this program:
>>
>> extern int printf(long long,...);
>>
>> int main(void) {
>> printf((long long)"Hello, World!\n");
>> }
>>
>> gcc complains that my printf conflicts with the built-in printf; so it
>> knows perfectly well what it is. It will even tell me if I get the
>> format codes wrong!
>
> You should know how things work (and 'long long' is sign that
> you prefer to complain instead of taking advantage of capabilites
> of gcc). As a little ilustration that printf is independent from
> gcc you can try the following (on Linux, see remarks below about
> Windows).
>
> You need two files, first called 'printf.c' second 'ts2a.c'.
>
> ---------------------<printf.c start>----------------------
>
> extern int printf(const char *f, ...);
>
> extern int putchar(int c);
> #include <stdarg.h>
> #include <string.h>
> int
> printf(const char *f, ...) {
> if (!strcmp(f, "%zu\n")) {
> va_list ap;
> va_start(ap, f);
> size_t val = va_arg(ap, size_t);
> va_end(ap);
> if ((val < 10) && (val >= 0)) {
> putchar('0'+val);
> putchar('\n');
> return 2;
> }
> }
> return 0;
> }
>
> ---------------------<printf.c end>------------------------
>
> ---------------------<ts2a.c start>------------------------
> extern int printf(const char *f, ...);
>
> int main(void) {
> printf("%zu\n", sizeof(void*));
> }
>
> ---------------------<ts2a.c end>--------------------------
>
> First compile printf.c:
>
> gcc -Wall -O -c printf.c
>
> Then compile test program:
>
> gcc -Wall -O ts2a.c printf.o -o ts2a
>
> Resulting program uses 'printf' defined in 'printf.c'. Of course,
> this is silly implementation handling only single format string,
> but using the similar principle one can create full version.
> More elegant solution would put new printf (and variations of
> printf) in a new library (say 'libmyc'). Linking with 'libmyc'
> would give you better version of selected standard function
> and allow use of other functions from system library. You can
> do equivalent of this on Windows. Sorry, I will not give you
> details, I did such things on (more precisly for) Windows
> in the past but it you who apparently cares about Windows,
> so it is for you to do the homework.
>

Sorry, I don't know what your example is supposed to show.

As it is, your printf is close enough to the real printf for gcc not to
complain. Although when I compile ts2a.c (c.c below) with gcc -Wall, it
warns about the unknown "z" in the "%zu" specifier:

C:\c>gcc -c -Wall c.c
c.c: In function 'main':
c.c:4:14: warning: unknown conversion type character 'z' in format
[-Wformat=]
4 | printf("%zu\n", sizeof(void*));
| ^
c.c:4:12: warning: too many arguments for format [-Wformat-extra-args]
4 | printf("%zu\n", sizeof(void*));
| ^~~~~~~

Try something a little more radical like compiling this program:

int printf(int);

I get:

C:\c>gcc c.c
c.c:1:5: warning: conflicting types for built-in function 'printf';
expected 'int(const char *, ...)
' [-Wbuiltin-declaration-mismatch]
1 | int printf(int);
| ^~~~~~
c.c:1:1: note: 'printf' is declared in header '<stdio.h>'
+++ |+#include <stdio.h>
1 | int printf(int);

I don't even need extra warning options. A project I'm working on now
may need to away with standard headers and define functions such as
printf as:

extern i32 printf(u64, ...);

So it will need special options to shut gcc up.

On 31/07/2021 00:36, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 30/07/2021 23:34, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> For the record, my current 'gcc' that I use on plain Windows is this
>>>> product:
>>>>
>>>> https://jmeubank.github.io/tdm-gcc/download/
>>> https://jmeubank.github.io/tdm-gcc/about/ :
>>> TDM-GCC is a compiler suite for Windows.
>>> It combines the most recent stable release of the GCC compiler,
>>> a
>>> few patches for Windows-friendliness, and the free and open-source
>>> MinGW.org or MinGW-w64 runtime APIs, to create a more lightweight
>>> open-source alternative to Microsoft’s compiler and platform SDK.
>>> TDM-GCC is not a compiler.
>>> TDM-GCC is not gcc.
>>> TDM-GCC is not produced or maintained by the gcc project.
>>> TDM-GCC is a software package that combines a compiler (gcc) and
>>> other
>>> components (MinGW runtime libraries, probably other things) into a C
>>> implementation.
>>> Other software packages might combine the gcc compiler with other
>>> runtime library implementations. For example, there are packages that
>>> combine the gcc compiler with Microsoft's runtime library.
>>> If any of the above is inaccurate, Bart, I encourage you to correct
>>> me.
>>> You seem to imply that TDM-GCC gives you an implementation that by
>>> default uses the obsolete MSVCRT.DLL, and therefore does not support
>>> "%zu". I find that at least mildly surprising. I might install it
>>> myself over the weekend to see what's going on.
>>
>> C:\c>type c.c
>> #include <stdio.h>
>> int main(void) {
>> printf("Hello, World! %zu\n",sizeof(void*));
>> }
>>
>> C:\c>gcc --version
>> gcc (tdm64-1) 9.2.0
>> <snip>
>>
>> C:\c>gcc c.c
>>
>> C:\c>a
>> Hello, World! zu
>>
>> C:\c>gcc c.c -lucrt
>>
>> C:\c>a
>> Hello, World! 8
>>
>> C:\c>gcc c.c \tdm\x86_64-w64-mingw32\lib\libmsvcrt.a
>>
>> C:\c>a
>> Hello, World! zu
>>
>> C:\c>
>
> OK, that demonstrates that TDM-GCC by default does not support "%zu".
> It doesn't directly demonstrate that it uses MSVCRT.DLL, but that's
> probably the most likely explanation.

A program compiled with or without -lucrt will import msvcrt.dll (from
looking inside the exe file). But it only imports vfprintf() that is
relevant.

(gcc's stdio.h defines printf in terms of __mingw_vfprintf, so will not
import printf directly.)

>
> Did you want to reply to anything else I wrote? Should I assume that
> you agree with the points I made above? (I would greatly appreciate a
> direct reply to that last question.)
>

Those seem to be your conclusions (not sure how you got those from that
About page). But I can't see the point of arguing about this.

That page is right: tdm-gcc is unlike other compilers, but I would
extend that to say that gcc (whatever it is) is quite unlike other
whatevers of its type.

Step away from the crazy world of the Unix (etc) ecosystem, and my
experience of compilers is rather different.

(I used an analogy once of buying a car. For your money, you expect it
to come with the necessary features such as an engine, and 4 wheels.
Everthing needed to drive from A to B. Just don't buy a car from the
people who wrote gcc...)

On 2021-07-30, Bart <bc@freeuk.com> wrote:
> On 30/07/2021 15:55, Kaz Kylheku wrote:
>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>> It's Windows 7. gcc is version 9.2.0.
>>
>>> This program:
>>>
>>> #include <stdio.h>
>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>
>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>
>> The above has no meaning. "gcc" is not the name of any software that
>> provides a printf function.
>>
>
> OK. But gcc and tcc are products that you expect to make the necessary
> arrangements for ensuring they your program can call a C standard
> function called "printf".

Umm, no. For instance, GCC is used for compiling various embedded
code bases that do not have a printf. (One example being the Linux
kernel, which has printk.)

GCC has diagnostic features to help find problems statically
in calls to printf-like functions.

Using GCC extensiosn, you can easily arrange this for your own
functions.

> Which they do, because it generally works. But whatever it is they end
> up linking into your program, doesn't support "zu".
>
> I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
> Which library do gcc and tcc use?

There is somnething called "libgcc" associated with GCC. This is
run-time support for compiled code. For instance, numeric routines
for operations that the compiler doesn't want to emit in-line.

Bart <bc@freeuk.com> writes:
> On 31/07/2021 00:36, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 30/07/2021 23:34, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> For the record, my current 'gcc' that I use on plain Windows is this
>>>>> product:
>>>>>
>>>>> https://jmeubank.github.io/tdm-gcc/download/
>>>> https://jmeubank.github.io/tdm-gcc/about/ :
>>>> TDM-GCC is a compiler suite for Windows.
>>>> It combines the most recent stable release of the GCC compiler, a
>>>> few patches for Windows-friendliness, and the free and open-source
>>>> MinGW.org or MinGW-w64 runtime APIs, to create a more lightweight
>>>> open-source alternative to Microsoft’s compiler and platform SDK.
>>>> TDM-GCC is not a compiler.
>>>> TDM-GCC is not gcc.
>>>> TDM-GCC is not produced or maintained by the gcc project.
>>>> TDM-GCC is a software package that combines a compiler (gcc) and
>>>> other
>>>> components (MinGW runtime libraries, probably other things) into a C
>>>> implementation.
>>>> Other software packages might combine the gcc compiler with other
>>>> runtime library implementations. For example, there are packages that
>>>> combine the gcc compiler with Microsoft's runtime library.
>>>> If any of the above is inaccurate, Bart, I encourage you to correct
>>>> me.
>>>> You seem to imply that TDM-GCC gives you an implementation that by
>>>> default uses the obsolete MSVCRT.DLL, and therefore does not support
>>>> "%zu". I find that at least mildly surprising. I might install it
>>>> myself over the weekend to see what's going on.
>>>
>>> C:\c>type c.c
>>> #include <stdio.h>
>>> int main(void) {
>>> printf("Hello, World! %zu\n",sizeof(void*));
>>> }
>>>
>>> C:\c>gcc --version
>>> gcc (tdm64-1) 9.2.0
>>> <snip>
>>>
>>> C:\c>gcc c.c
>>>
>>> C:\c>a
>>> Hello, World! zu
>>>
>>> C:\c>gcc c.c -lucrt
>>>
>>> C:\c>a
>>> Hello, World! 8
>>>
>>> C:\c>gcc c.c \tdm\x86_64-w64-mingw32\lib\libmsvcrt.a
>>>
>>> C:\c>a
>>> Hello, World! zu
>>>
>>> C:\c>
>> OK, that demonstrates that TDM-GCC by default does not support
>> "%zu".
>> It doesn't directly demonstrate that it uses MSVCRT.DLL, but that's
>> probably the most likely explanation.
>
> A program compiled with or without -lucrt will import msvcrt.dll (from
> looking inside the exe file). But it only imports vfprintf() that is
> relevant.
>
> (gcc's stdio.h defines printf in terms of __mingw_vfprintf, so will
> not import printf directly.)
>
>> Did you want to reply to anything else I wrote? Should I assume
>> that
>> you agree with the points I made above? (I would greatly appreciate a
>> direct reply to that last question.)
>
> Those seem to be your conclusions (not sure how you got those from
> that About page). But I can't see the point of arguing about this.

I believe there is a point.

You very commonly gloss over the distinction between an *implementation*
and a *compiler*. An implementation consists of several components; the
compiler is just one of them.

In this thread, you've talked about what "gcc" supports, only later
mentioning that you're using "TDM-GCC".

I would have liked an explicit acknowledgement from you that you
understand the difference.

> That page is right: tdm-gcc is unlike other compilers, but I would
> extend that to say that gcc (whatever it is) is quite unlike other
> whatevers of its type.

TDM-GCC is not a compiler. It's an implementation.

gcc *is* a compiler. It can be part of an implementation.

Do you understand that? Do you disagree? Are you being deliberately
evasive?

> Step away from the crazy world of the Unix (etc) ecosystem, and my
> experience of compilers is rather different.

I'm sure it is. For one thing, implementations targeted for Windows
seem to be more commonly distributed as a single installable package
that includes the various components (compiler, library, linker), while
implementations targeted for Unix-like systems more typically do not
(for example I can install gcc and clang as separate packages, and each
of them will work with glibc, which is a separate component).

And I suppose I should mention that the "gcc" command, typically
/usr/bin/gcc on Linux-based systems, is a driver program that invokes
several other programs (for example front end "cc1", assembler "as"
linker "ld"). That driver program is provided as part of the "gcc"
package, and can for example invoke a different linker or tell the
linker to use a different library as needed.

BTW, I'm not arguing that either approach is better.

> (I used an analogy once of buying a car. For your money, you expect it
> to come with the necessary features such as an engine, and 4 wheels.
> Everthing needed to drive from A to B. Just don't buy a car from the
> people who wrote gcc...)

Continuing the analogy, of course you wouldn't buy a car from the people
who wrote gcc. They don't sell cars. They sell engines.

That's why *you* went to a car dealership to get TDM-GCC rather than to
an engine manufacturer to get gcc.

If I want a usable C implementation on Ubuntu, for example, I can
install the "gcc" package, which will automatically install several
other packages that it depends on, including libc6 and binutils (the
latter includes the linker). (There are also meta-packages that install
a more general development environment.)

If I want a usable C implementation on Windows (not using Cygwin or
something similar), I can install TDM-GCC, which includes gcc *and*
other components that make up a working C implementation. Or I can get
Visual Studio from Microsoft.

My hope was that, if you acknowledged the simple fact that a compiler is
*part* of an implementation, and that gcc is just a compiler, we could
avoid wasting time in the future.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Kaz Kylheku <563-365-8930@kylheku.com> writes:
> On 2021-07-30, Bart <bc@freeuk.com> wrote:
>> On 30/07/2021 15:55, Kaz Kylheku wrote:
[...]
>> Which they do, because it generally works. But whatever it is they end
>> up linking into your program, doesn't support "zu".
>>
>> I use msvcrt.dll for my compiler's library (sometimes, ucrtbase.dll).
>> Which library do gcc and tcc use?
>
> There is somnething called "libgcc" associated with GCC. This is
> run-time support for compiled code. For instance, numeric routines
> for operations that the compiler doesn't want to emit in-line.

And to be clear (for Bart's possible benefit), msvcrt.dll is an outdated
C library implementation that provides things like printf, while libgcc
is a more limited library that provides features that are more tightly
tied to the compiler than to the library implementation, such as
<stdbool.h>, <stdarg.h>, and low-level startup and shutdown code.

gcc and tcc will of course use other libraries as well in most cases,
depending on how the implementation is configured.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 31/07/2021 00:36, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 30/07/2021 23:34, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> For the record, my current 'gcc' that I use on plain Windows is this
>>>> product:
>>>>
>>>> https://jmeubank.github.io/tdm-gcc/download/
>>> https://jmeubank.github.io/tdm-gcc/about/ :
>>> TDM-GCC is a compiler suite for Windows.
>>> It combines the most recent stable release of the GCC compiler,
>>> a
>>> few patches for Windows-friendliness, and the free and open-source
>>> MinGW.org or MinGW-w64 runtime APIs, to create a more lightweight
>>> open-source alternative to Microsoft’s compiler and platform SDK.
>>> TDM-GCC is not a compiler.
>>> TDM-GCC is not gcc.
>>> TDM-GCC is not produced or maintained by the gcc project.
>>> TDM-GCC is a software package that combines a compiler (gcc) and
>>> other
>>> components (MinGW runtime libraries, probably other things) into a C
>>> implementation.
>>> Other software packages might combine the gcc compiler with other
>>> runtime library implementations. For example, there are packages that
>>> combine the gcc compiler with Microsoft's runtime library.
>>> If any of the above is inaccurate, Bart, I encourage you to correct
>>> me.
>>> You seem to imply that TDM-GCC gives you an implementation that by
>>> default uses the obsolete MSVCRT.DLL, and therefore does not support
>>> "%zu". I find that at least mildly surprising. I might install it
>>> myself over the weekend to see what's going on.
>>
>> C:\c>type c.c
>> #include <stdio.h>
>> int main(void) {
>> printf("Hello, World! %zu\n",sizeof(void*));
>> }
>>
>> C:\c>gcc --version
>> gcc (tdm64-1) 9.2.0
>> <snip>
>>
>> C:\c>gcc c.c
>>
>> C:\c>a
>> Hello, World! zu
>>
>> C:\c>gcc c.c -lucrt
>>
>> C:\c>a
>> Hello, World! 8
>>
>> C:\c>gcc c.c \tdm\x86_64-w64-mingw32\lib\libmsvcrt.a
>>
>> C:\c>a
>> Hello, World! zu
>>
>> C:\c>
>
> OK, that demonstrates that TDM-GCC by default does not support "%zu".
> It doesn't directly demonstrate that it uses MSVCRT.DLL, but that's
> probably the most likely explanation.

These are the parameters passed to ld.exe when I run 'gcc hello.c':

1:
c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe
2: -plugin
3: c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/9.2.0/liblto_plugin-0.dll
4:
-plugin-opt=c:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/9.2.0/lto-wrapper.exe
5:
-plugin-opt=-fresolution=C:\Users\DESKTO~1\AppData\Local\Temp\ccaMoeZ1.res
6: -plugin-opt=-pass-through=-lmingw32
7: -plugin-opt=-pass-through=-lgcc
8: -plugin-opt=-pass-through=-lmoldname
9: -plugin-opt=-pass-through=-lmingwex
10: -plugin-opt=-pass-through=-lmsvcrt
11: -plugin-opt=-pass-through=-lpthread
12: -plugin-opt=-pass-through=-ladvapi32
13: -plugin-opt=-pass-through=-lshell32
14: -plugin-opt=-pass-through=-luser32
15: -plugin-opt=-pass-through=-lkernel32
16: -plugin-opt=-pass-through=-lmingw32
17: -plugin-opt=-pass-through=-lgcc
18: -plugin-opt=-pass-through=-lmoldname
19: -plugin-opt=-pass-through=-lmingwex
20: -plugin-opt=-pass-through=-lmsvcrt
21: -m
22: i386pep
23: --exclude-libs=libpthread.a
24: -Bdynamic
25:
c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o
26: c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/crtbegin.o
27: -Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0
28: -Lc:/tdm/bin/../lib/gcc
29:
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib
30: -Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../lib
31:
-Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib
32: -Lc:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../..
33: C:\Users\DESKTO~1\AppData\Local\Temp\ccU32yvY.o
34: -lmingw32
35: -lgcc
36: -lmoldname
37: -lmingwex
38: -lmsvcrt
39: -lpthread
40: -ladvapi32
41: -lshell32
42: -luser32
43: -lkernel32
44: -lmingw32
45: -lgcc
46: -lmoldname
47: -lmingwex
48: -lmsvcrt
49:
c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/lib/../lib/default-manifest.o
50: c:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/crtend.o

-lmsvcrt is used twice (for good measure I guess).

When I use -lucrt, then it adds '-lucrt' between line 33 and 34;
-lmsvcrt is still used.

Inside my bcc product, it automatically sets up these 4 libraries, done
internally as there is no separate linker:

searchlibs[1]:="msvcrt"
searchlibs[2]:="gdi32"
searchlibs[3]:="user32"
searchlibs[4]:="kernel32"

Here, each name refers to a DLL file which needs to be in Windows' set
of search paths; but these system DLLs (inside \windows\system32)
alsways are. The ld.exe ones I believe refer to lib*.a files.

On 31/07/2021 03:14, Kaz Kylheku wrote:
> On 2021-07-30, Bart <bc@freeuk.com> wrote:
>> On 30/07/2021 15:55, Kaz Kylheku wrote:
>>> On 2021-07-29, Bart <bc@freeuk.com> wrote:
>>>> It's Windows 7. gcc is version 9.2.0.
>>>
>>>> This program:
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {printf("%zu\n",sizeof(void*));}
>>>>
>>>> displays 'zu' with gcc, tcc and bcc (my product that uses msvcrt.dll).
>>>
>>> The above has no meaning. "gcc" is not the name of any software that
>>> provides a printf function.
>>>
>>
>> OK. But gcc and tcc are products that you expect to make the necessary
>> arrangements for ensuring they your program can call a C standard
>> function called "printf".
>
> Umm, no. For instance, GCC is used for compiling various embedded
> code bases that do not have a printf. (One example being the Linux
> kernel, which has printk.)

And?

If I look at K&R2 page 6, they show the hello-world example that uses
printf(), and suggest it is built using:

cc hello.c

This seems to magically work, in exactly the same way that:

gcc hello.c

does on Windows. They even both create an executable starting with "a"
(a.out vs a.exe).

Are you going to accuse Kernighan and Ritchie about making unwarranted
assumptions about what a compiler is and isn't?

> GCC is used for compiling various embedded
> code bases that do not have a printf. (One example being the Linux
> kernel, which has printk.)

I think I was coding for nearly 20 years before I first used printf in C.

On 31/07/2021 02:51, Bart wrote:
> On 30/07/2021 22:16, David Brown wrote:
>> On 30/07/2021 21:03, Bart wrote:
>

>>> How big would a program be if it incorporated half the Windows API as
>>> statically linked code?
>>>
>>
>> For someone who claims to have developed their own languages, compilers,
>> linkers and other tools for decades, you are remarkably ignorant of how
>> toolchains work.
>
> Why, what's wrong with my question? It is perfectly reasonable.
>
> I might consider bundling RAYLIB with an application for example, by
> statically linking (it's some 3MB I think). But not libraries which are
> guaranteed to come with the OS.
>
> (Some exceptions such as OpenGL where the OS one may lag behind.)
>
>> Or you are trolling, as some people have suggested.
>> Perhaps you have just written in haste, without thinking - everyone
>> makes mistakes and occasionally writes something stupid.
>
> OK, now I'm curious; what's the thing that is stupid? Having an opinion
> different from yours?
>

When you use statically linked libraries, you only link in the functions
you actually /use/. So it doesn't matter if the static library supports
a hundred thousand WinAPI functions and weighs in at 100 MB - if you use
a hundred functions, the library will give you an extra 100 KB in your
binary. Using a static library for the WinAPI or the C standard library
is only going to give you a big binary if you use a very large number of
functions from the library - in which case your binary is already very big.

>
>>> You just want to pour more scorn on the efforts of amateur compiler
>>> writers.
>>>
>>
>> Given that there are other free C runtime libraries, I don't see any
>> good reason for using it when you simply want C coding,
>
> I don't like dependencies. I like that there is just my program, and the
> OS. Some third party libraries may necessarily have to be sourced, but
> MSVCRT.DLL works perfectly well for the vast majority of my needs.

I understand not wanting dependencies, and preferring a stand-alone
program. That is another good reason to ditch MSVCRT.DLL, which is a
completely unnecessary dependency, and statically link a C library.

>
> (From my private language, I only use about 20 C functions anyway, out
> of about 1400 in MSVCRT.DLL.
>
> It wouldn't be that hard to eliminate it (I did without it for years).)
>
>  without a
>> specific need for compatibility with (older) MS tools.  It is quite
>> possible that MSVCRT.DLL was the best choice in the past - it is not
>> now.  I can't say I have looked into this in too much detail, since it
>> is not an issue that is at all relevant to me or my work.  But I could
>> point out that at least two people here have shown the use of gcc with C
>> libraries that are quite happy with C99 printf.  One - Keith - said he
>> had no trouble when using Cygwin.
>
> I use Windows. (Imagine someone said they had no problem running my
> Windows program under Wine; but Wine isn't Linux)

I see "runs fine with Wine" as a reasonable solution to porting Windows
programs to run on Linux - just as Cygwin is a reasonable solution to
porting POSIX programs to Windows. It's not native, but it works well
for many purposes.

>
>> Someone else - I forget who - said
>> they could just use the "-lucrt" switch to get a working library.
>
> That was me. But it's not a solution (assuming there was a problem in
> the first place) as I need to have C code run under bcc and tcc.

It is a solution for when you want to use a C compiler, rather than a
compiler for a limited subset of C. If you want C, you need a real
compiler and a real library. If you are happy with just part of C (and
often that is sufficient), you can use a limited tool like bcc or tcc,
and a limited library like MSVCRT.DLL, if you like. Just don't complain
when you use such tools and they don't handle some valid C code.

> Especially tcc, since I have an upcoming project that may need a C
> backend (and for some challenging C code), and using any other compiler
> would be like hitting a brick wall.
>
>> But let me rephrase.  Anyone competent and interested in compiling gcc,
>> can take the source code and compile it and package it in whatever way
>> they like.
>
> Not interested. Life is too short. My entire compiler builds in 0.2
> seconds, but might generate code 50% slower than gcc. That will do me.
>
>
>>> That is a totally different world from what I do. My product doesn't
>>> even HAVE a linker! (Because it doesn't need it; an obsolete concept in
>>> my view.)
>>>
>>
>> Yes, but your tools are useless for anyone but you.
>
> Sure. But they are also proof of concept. Want a blazing fast C
> compiler? I've done it! (Tcc got there first and better, but I'm not far
> behind.)

Why should anyone care about how fast something runs if it does not do
the job? If these niche tools are good enough for your particular
needs, fine - use them and enjoy them. There is a place in this world
for Formula 1 cars that are lighter, smaller, and much faster than
normal cars - but only a fool would think they are /better/ than the car
you drive every day.

>
> Do away with object files? I've done it! Do away with a linker? I've
> done it! Do away with makefiles? I've done it! Write a whole-program
> compiler? I've done it! (But not with C - yet.) A 4-million-line-per
> second assembler? I've done it!

I have always been impressed by the fact that you have written a
compiler at all. Your obsession with speed and size, however, is less
impressive.

>
> So it can all show what is possible. Of little interest in this group
> obviously and especially to you because you don't understand that some
> of us are interested in developing efficient, minimalist, human-scale
> tools, and which might be an inspiration to others.
>

I can appreciate people making hobby tools.

>
>> gcc (and binutils
>> for the linker, assuming that's the linker you are using) are designed
>> to be used by vast numbers of people for vast numbers of different
>> purposes in vast numbers of different circumstances.
>>
>> Do you also complain about the size of supermarkets, or the number of
>> restaurants in your town, just because you are happy with a cheese
>> sandwich for dinner every night?
>
> I would like to cook my own recipes without getting involved in
> industrial-scale food production. There's a need for that, obviously,
> but I'm simply not interested.
>
>> Look, no one gives a ***** about your private little toy language.  No
>> one cares. It is useless for anything real.
>
> I would let that go. But actually, I worked in a commercial environment
> for 20 years and used exclusively my private languages.
>
> They /were/ useful, and were used for a product that was generating,
> then, perhaps $1m a year of business. So I'm not going to be shouted
> down by you.
>

I have seen the mistakes made by customers getting software written with
"one-man" tools. It can sound like a good idea at the time, but leaves
the customer with unmaintainable code. /Sometimes/ it can be a
reasonable choice, especially when the system is highly person-specific
in the first place and using a language known by others would not help.
And it used to be more common long ago, in the "cowboy days" of
software development.

>
>   Even if it was the
>> greatest invention since sliced bread, no one would use it because it is
>> the product of one angry little man whose prime motivation is a bizarre
>> and obsessive hatred of C (and C++) and tools for those languages.
>
> This entire subthread is a perfect example of what I hate about it: all
> this fuss about a stupid "%zu" format code just to print out a number.
>

Just use a C toolchain and the C language, as it is defined - it's not
hard. It's only people who haven't joined this century that have problems.

> Whose idea was that? And how about /properly/ fixing 'print'?
>

If we were discussing how a programming language could handle tasks in a
different way from the C way, that would come up. No one is in any
doubt that a programming language designed today would be somewhat
different from one designed 50 years ago. But this is about how to
write code in C.

>
>
>> This
>> is comp.lang.c, where we use and discuss C.
>
> I knew it was a mistake coming back to this newsgroup.
>
> You know, because of the massive negative reaction in this group
> (everthing I did was wrong, all my C code was rubbish, I knew nothing
> about the language, etc etc) a year ago I burnt most of my bridges with
> C, got rid of my C backends; actually you guys put me off the language a
> lot more than the language itself.
>
> That was a mistake. A C target is genuinely useful to have. And you
> people don't actually own the language. Neither do you write any of the
> tools, mostly (some exceptions like JN).
>
> And, you can't actually tell people what they can or can't do (go and
> program in WSL; no thanks!).
>
> So I'm resurrecting that C target in a novel, experimental project. I
> won't make the mistake of posting code here for you to shoot down. And I
> will use whatever compilers I like with the libraries I want and on the
> OSes that I choose.
>

On 31/07/2021 12:42, David Brown wrote:
> On 31/07/2021 02:51, Bart wrote:
>> On 30/07/2021 22:16, David Brown wrote:
>>> On 30/07/2021 21:03, Bart wrote:
>>
>
>>>> How big would a program be if it incorporated half the Windows API as
>>>> statically linked code?
>>>>
>>>
>>> For someone who claims to have developed their own languages, compilers,
>>> linkers and other tools for decades, you are remarkably ignorant of how
>>> toolchains work.
>>
>> Why, what's wrong with my question? It is perfectly reasonable.
>>
>> I might consider bundling RAYLIB with an application for example, by
>> statically linking (it's some 3MB I think). But not libraries which are
>> guaranteed to come with the OS.
>>
>> (Some exceptions such as OpenGL where the OS one may lag behind.)
>>
>>> Or you are trolling, as some people have suggested.
>>> Perhaps you have just written in haste, without thinking - everyone
>>> makes mistakes and occasionally writes something stupid.
>>
>> OK, now I'm curious; what's the thing that is stupid? Having an opinion
>> different from yours?
>>
>
> When you use statically linked libraries, you only link in the functions
> you actually /use/. So it doesn't matter if the static library supports
> a hundred thousand WinAPI functions and weighs in at 100 MB - if you use
> a hundred functions, the library will give you an extra 100 KB in your
> binary. Using a static library for the WinAPI or the C standard library
> is only going to give you a big binary if you use a very large number of
> functions from the library - in which case your binary is already very big.

I don't think this is right. My brief experiments seem to show:

* If you link in biglib.o, it will include everything from biglib,
whether or not used from outside

* If you create biglib.a, and link in biglib.a, it will still include
everything in biglib, provided at least one export is used elsewhere

But my experiments only covered a .a file made from a single .o file.

It could be that it works on a granularity of individual object files.
But even then, if A and B each have 1000 functions, and you use one
function in A which calls one in B, then 2000 functions will get
included, not even only 1000.

This is some way from your suggestion that the granularity is at the
level of individual files, and presumably individual variables.

But I guess this all magically becomes possible with special options,
including options that will generate the position-independent code that
would be necessary to extract and relocate individual functions. (How
does it even work out how big a function is?)

On 7/31/2021 3:56 PM, Bart wrote:
> On 31/07/2021 12:42, David Brown wrote:
>> On 31/07/2021 02:51, Bart wrote:
>>> On 30/07/2021 22:16, David Brown wrote:
>>>> On 30/07/2021 21:03, Bart wrote:
>>>
>>
>>>>> How big would a program be if it incorporated half the Windows API as
>>>>> statically linked code?
>>>>>
>>>>
>>>> For someone who claims to have developed their own languages,
>>>> compilers,
>>>> linkers and other tools for decades, you are remarkably ignorant of how
>>>> toolchains work.
>>>
>>> Why, what's wrong with my question? It is perfectly reasonable.
>>>
>>> I might consider bundling RAYLIB with an application for example, by
>>> statically linking (it's some 3MB I think). But not libraries which are
>>> guaranteed to come with the OS.
>>>
>>> (Some exceptions such as OpenGL where the OS one may lag behind.)
>>>
>>>> Or you are trolling, as some people have suggested.
>>>> Perhaps you have just written in haste, without thinking - everyone
>>>> makes mistakes and occasionally writes something stupid.
>>>
>>> OK, now I'm curious; what's the thing that is stupid? Having an opinion
>>> different from yours?
>>>
>>
>> When you use statically linked libraries, you only link in the functions
>> you actually /use/.  So it doesn't matter if the static library supports
>> a hundred thousand WinAPI functions and weighs in at 100 MB - if you use
>> a hundred functions, the library will give you an extra 100 KB in your
>> binary.  Using a static library for the WinAPI or the C standard library
>> is only going to give you a big binary if you use a very large number of
>> functions from the library - in which case your binary is already very
>> big.
>
> I don't think this is right.
No, it is right.

My brief experiments seem to show:
>
> * If you link in biglib.o, it will include everything from biglib,
> whether or not used from outside
>
> * If you create biglib.a, and link in biglib.a, it will still include
> everything in biglib, provided at least one export is used elsewhere
>
> But my experiments only covered a .a file made from a single .o file.

That's the difference. You should test it with a final executable (and a
decent compiler). (btw I assume you didn't mean .a as a linux library,
so what did you mean with .a ?)

>
> It could be that it works on a granularity of individual object files.
> But even then, if A and B each have 1000 functions, and you use one
> function in A which calls one in B, then 2000 functions will get
> included, not even only 1000.
>
> This is some way from your suggestion that the granularity is at the
> level of individual files, and presumably individual variables.

That is how static libraries work with decent compilers, the final
executable only gets individual /functions/ (not files, but obviously
all of the function dependencies) and individual variables. Note, stress
is on /static/ libraries (.lib on Windows and .a on Linux, so no .dll or
..so statically linked, in case this were a thing)

>
> But I guess this all magically becomes possible with special options,
> including options that will generate the position-independent code that
> would be necessary to extract and relocate individual functions. (How
> does it even work out how big a function is?)
>

On 31/07/2021 18:33, Manfred wrote:
> On 7/31/2021 3:56 PM, Bart wrote:

>>> When you use statically linked libraries, you only link in the functions
>>> you actually /use/.  So it doesn't matter if the static library supports
>>> a hundred thousand WinAPI functions and weighs in at 100 MB - if you use
>>> a hundred functions, the library will give you an extra 100 KB in your
>>> binary.  Using a static library for the WinAPI or the C standard library
>>> is only going to give you a big binary if you use a very large number of
>>> functions from the library - in which case your binary is already
>>> very big.
>>
>> I don't think this is right.
> No, it is right.
>
>  My brief experiments seem to show:
>>
>> * If you link in biglib.o, it will include everything from biglib,
>> whether or not used from outside
>>
>> * If you create biglib.a, and link in biglib.a, it will still include
>> everything in biglib, provided at least one export is used elsewhere
>>
>> But my experiments only covered a .a file made from a single .o file.
>
> That's the difference. You should test it with a final executable (and a
> decent compiler). (btw I assume you didn't mean .a as a linux library,
> so what did you mean with .a ?)

I'm using tdm-gcc on Windows, which uses .a files as they are on Linux,
created with the 'ar' utility.

>>
>> It could be that it works on a granularity of individual object files.
>> But even then, if A and B each have 1000 functions, and you use one
>> function in A which calls one in B, then 2000 functions will get
>> included, not even only 1000.
>>
>> This is some way from your suggestion that the granularity is at the
>> level of individual files, and presumably individual variables.
>
> That is how static libraries work with decent compilers, the final
> executable only gets individual /functions/ (not files, but obviously
> all of the function dependencies) and individual variables. Note, stress
> is on /static/ libraries (.lib on Windows and .a on Linux, so no .dll or
> .so statically linked, in case this were a thing)

My tests with a 4MB library, libraylib_static.a, showed a program with
just one reference to one symbol, resulted in executables from
2.7-3.0MB, where an empty program is 0.3MB (normal with tdm-gcc).

If I used the -s option, sizes reduce to 0.02MB (empty) to 0.8-1.0MB
(single reference, including one to an exported variable, not a function).

So it does seem that it uses granularity of a module at best. It seems
odd though that the linker doesn't by default, exclude that symbol info
which makes a very significant difference, but doesn't, assuming it was
capable, eliminate unused functions.

I guess now this is going to be the start of another long subthread
about how this is all my fault; I should read all the docs for tdm-gcc
so that I know how to tell it to /do its job/, how I should just give up
Windows right now, blah blah.

But I'm not going there. DB said linkers work a certain way, and I just
posted my observations about how they work a different way. This was
after being called stupid for suggesting that static linking might
result in large executables.

(Actually, given how huge some applications already are, it would be
scary if that was /after/ all unnecessary functions had been eliminated!)

Bart <bc@freeuk.com> wrote:
> On 31/07/2021 12:42, David Brown wrote:
> > On 31/07/2021 02:51, Bart wrote:
> >> On 30/07/2021 22:16, David Brown wrote:
> >>> On 30/07/2021 21:03, Bart wrote:
> >>
> >
> >>>> How big would a program be if it incorporated half the Windows API as
> >>>> statically linked code?
> >>>>
> >>>
> >>> For someone who claims to have developed their own languages, compilers,
> >>> linkers and other tools for decades, you are remarkably ignorant of how
> >>> toolchains work.
> >>
> >> Why, what's wrong with my question? It is perfectly reasonable.
> >>
> >> I might consider bundling RAYLIB with an application for example, by
> >> statically linking (it's some 3MB I think). But not libraries which are
> >> guaranteed to come with the OS.
> >>
> >> (Some exceptions such as OpenGL where the OS one may lag behind.)
> >>
> >>> Or you are trolling, as some people have suggested.
> >>> Perhaps you have just written in haste, without thinking - everyone
> >>> makes mistakes and occasionally writes something stupid.
> >>
> >> OK, now I'm curious; what's the thing that is stupid? Having an opinion
> >> different from yours?
> >>
> >
> > When you use statically linked libraries, you only link in the functions
> > you actually /use/. So it doesn't matter if the static library supports
> > a hundred thousand WinAPI functions and weighs in at 100 MB - if you use
> > a hundred functions, the library will give you an extra 100 KB in your
> > binary. Using a static library for the WinAPI or the C standard library
> > is only going to give you a big binary if you use a very large number of
> > functions from the library - in which case your binary is already very big.
>
> I don't think this is right.

David presented too rosy picture (more below). But your tests
ignore how things are supposed to work, so only say something
about you, not about size of statically linked libraries.

> My brief experiments seem to show:
>
> * If you link in biglib.o, it will include everything from biglib,
> whether or not used from outside

That is traditional behaviour of linkers, no surprize here.
> * If you create biglib.a, and link in biglib.a, it will still include
> everything in biglib, provided at least one export is used elsewhere

Again no suprize.

> But my experiments only covered a .a file made from a single .o file.

Yes, that big mistake. Traditional .a library is supposed to have
..o file per function, then you linker includes only function that
you include directly or indirectly.

> It could be that it works on a granularity of individual object files.
> But even then, if A and B each have 1000 functions, and you use one
> function in A which calls one in B, then 2000 functions will get
> included, not even only 1000.
>
> This is some way from your suggestion that the granularity is at the
> level of individual files, and presumably individual variables.
>
> But I guess this all magically becomes possible with special options,

Yes. A lot of folks dislkied idea of splitting library into thousends
of small .c files in order to get separate .o files. Reasonably modern
version of gcc support '-ffunction-sections' option, which means
that each function will be a separate "unit" for linker (otherwise
whole .o file would be a unit). You need to compile all files
going into library using this option. When linking program
you need to use '--gc-sections' option. Both options together
work and may give desired result.

But there are traps. Probably biggest trap is OO code. In such
code typically each object has table of methods. If you use
object linker normally will pull table of methods and consequently
will pull _all_ methods for given object, even if you use
only one (possibly trivial) method. Each method will pull
object that they use. If you have inhertance chain and use
most specialized object linker will amist surely pull whole
inhertance chain. So in OO library with say 100 classes and
5000 methods as little as 10 methods may easily pull majority
of the library. Another trap is that function that you need
may have extra functionality that you do not need but which
will pull other things as dependencies. Notable example is
that function my detect errors. Even if you usage never leads
to errors such function will pull error handling support (for
example 'printf' to print error message). I have limited
knowledge about Windows API, but it is resonable to suspect
that that using just few functions could pull quite a lot
of code.

> including options that will generate the position-independent code that
> would be necessary to extract and relocate individual functions. (How
> does it even work out how big a function is?)

Here you completely messed up things: static linking does not
require position-independent code. In fact, one modtivation
for static linking is that position-dependent code is few
percent faster, so with static linking you can squese some
extra performance when it metters.

Concerning function size and relocations: that is contained
in .o file (apropriate tables are build by assembler).
I find it curious that somebody boasts about writing an
assembler, but apparently does not know what should go
into .o file...

--
Waldek Hebisch

On 7/31/2021 8:17 PM, Bart wrote:
> On 31/07/2021 18:33, Manfred wrote:
>> On 7/31/2021 3:56 PM, Bart wrote:
>
>>>> When you use statically linked libraries, you only link in the
>>>> functions
>>>> you actually /use/.  So it doesn't matter if the static library
>>>> supports
>>>> a hundred thousand WinAPI functions and weighs in at 100 MB - if you
>>>> use
>>>> a hundred functions, the library will give you an extra 100 KB in your
>>>> binary.  Using a static library for the WinAPI or the C standard
>>>> library
>>>> is only going to give you a big binary if you use a very large
>>>> number of
>>>> functions from the library - in which case your binary is already
>>>> very big.
>>>
>>> I don't think this is right.
>> No, it is right.
>>
>>   My brief experiments seem to show:
>>>
>>> * If you link in biglib.o, it will include everything from biglib,
>>> whether or not used from outside
>>>
>>> * If you create biglib.a, and link in biglib.a, it will still include
>>> everything in biglib, provided at least one export is used elsewhere
>>>
>>> But my experiments only covered a .a file made from a single .o file.
>>
>> That's the difference. You should test it with a final executable (and
>> a decent compiler). (btw I assume you didn't mean .a as a linux
>> library, so what did you mean with .a ?)
>
> I'm using tdm-gcc on Windows, which uses .a files as they are on Linux,
> created with the 'ar' utility.
>
>
>>>
>>> It could be that it works on a granularity of individual object
>>> files. But even then, if A and B each have 1000 functions, and you
>>> use one function in A which calls one in B, then 2000 functions will
>>> get included, not even only 1000.
>>>
>>> This is some way from your suggestion that the granularity is at the
>>> level of individual files, and presumably individual variables.
>>
>> That is how static libraries work with decent compilers, the final
>> executable only gets individual /functions/ (not files, but obviously
>> all of the function dependencies) and individual variables. Note,
>> stress is on /static/ libraries (.lib on Windows and .a on Linux, so
>> no .dll or .so statically linked, in case this were a thing)
>
>
> My tests with a 4MB library, libraylib_static.a, showed a program with
> just one reference to one symbol, resulted in executables from
> 2.7-3.0MB, where an empty program is 0.3MB (normal with tdm-gcc).
>
> If I used the -s option, sizes reduce to 0.02MB (empty) to 0.8-1.0MB
> (single reference, including one to an exported variable, not a function).
>
> So it does seem that it uses granularity of a module at best. It seems
> odd though that the linker doesn't by default, exclude that symbol info
> which makes a very significant difference, but doesn't, assuming it was
> capable, eliminate unused functions.

It turns out it's not that trivial, after my earlier reply I decided to
double check it, and in fact I had to ask google about it:
https://stackoverflow.com/questions/6687630/how-to-remove-unused-c-c-symbols-with-gcc-and-ld

In short:
compile with -fdata-sections -ffunction-sections
link with: --gc-sections (i.e. invoke gcc with -Wl,--gc-sections)

I verified that these options do get function level granularity.

The fact that it requires cooperation between compiler and linker
suggests that there are reasons for which this can't be done by default.

MSVC does the same if you make a pair of projects (lib + exec) in the
IDE, and it sets the applicable options by default for Release builds.

>
>
> I guess now this is going to be the start of another long subthread
> about how this is all my fault; I should read all the docs for tdm-gcc
> so that I know how to tell it to /do its job/, how I should just give up
> Windows right now, blah blah.

I won't start any of this - as I said it's not as trivial as it looks,
so it's not anyone's fault.

>
> But I'm not going there. DB said linkers work a certain way, and I just
> posted my observations about how they work a different way. This was
> after being called stupid for suggesting that static linking might
> result in large executables.
>
> (Actually, given how huge some applications already are, it would be
> scary if that was /after/ all unnecessary functions had been eliminated!)

Bart <bc@freeuk.com> wrote:
>
> Cygwin is an attempt to bring elements of Linux to Windows (along with
> MSYS2 and WSL). I would not count it as directly running a C compiler on
> Windows, and you can't really compare behaviour.

You are exagerating:
- Cygwin binaries are Windows binares (they will not run natively
on other systems)
- Cygwin gcc can create binaries which are independent of Cygwin
libraries. That is how MinGW was born: they used Cygwin gcc
and slightly modified sources of Cygwnin gcc but recompiled
gcc so that it does non use Cygwin libraries.

And for clarification: Cygwin provides Posix interface. That
is OS interface similar to Unix, but several vendors agreed
to support it. Those vendors included Microsoft, IBM (which
has propritary system quite different than Unix, but supports
Posix interface to it), DEC (they had VMS, but provided also
Posix interface on it). Microsoft for many years included
Posix interface in "professional" versions of Windows.
Posix subsystem in Windows had limitations, but was good
enough to run gcc under it. Cygwin point was to provide
"better" Posix subsystem and make it available also in
home versions.

BTW: IIUC Cygwin was created slightly earlier than Linux.
Later Cygnus (creators of Cygwin) were bought by Red Hat,
but AFAIK Cygwin project is an independent unit.

BTW2: After many years of neglect at some time Microsoft
tried to substantially improve their Posix subsystem.
IIUC later they decided instead to replace it by WSL.

--
Waldek Hebisch