Bart <bc@freeuk.com> writes:
> 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?

No, I'm not.

"cc" is as driver program that might invoke several different programs,
including a preprocessor, a compiler, an assembler, and a linker. It
was perfectly reasonable for K&R not to get into those details in the
"Getting Started" section.

The book isn't about teaching people how implementations work. It's
about teaching people to program in C. Details about how the tools work
are appropriately glossed over.

Someone learning to use a C implementation for an embedded target system
that doesn't support printf will need some resource other than K&R.

Kernighan and Ritchie did not repeatedly and stubbornly refuse to
acknowledge, when directly asked, that a compiler is just one component
of a C implementation. That was someone else.

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

Interesting. A more common time span for that is about 5 minutes.

I'm not saying there's anything wrong with your approach, but you are an
extreme outlier, and you cannot expect everyone to cater to your very
specific needs.

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

It clearly shows that printf is independent and that you can
easily replace it by your own. It shows advantage of having
a linker: you have control of what gets into your executable.

It shows that there is no excuse of sort "Windows does not
support it": if you want you can easily support it just
by implementing printf family, but reusing rest of msvcrt.

> 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);

Fact that printf is independent of compiler does not mean that
you should replace it by random garbage. In particular, it
make sense to use name 'printf' only when it is compatible
with requirements of C standard.
> 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, ...);

Once you do "#include <stdio.h>" compiler may assume than printf
is standard compliant. I leave to others checking if such prototype
is legal, but regardless of legality using such prototype is
asking for trouble. But you want troubles, without troubles you
would have nothing to complain about...

--
Waldek Hebisch

On Sat, 31 Jul 2021 12:58:52 -0700, Keith Thompson wrote:

> Bart <bc@freeuk.com> writes:
[snip]
>> Are you going to accuse Kernighan and Ritchie about making unwarranted
>> assumptions about what a compiler is and isn't?
>
> No, I'm not.
>
> "cc" is as driver program that might invoke several different programs,
> including a preprocessor, a compiler, an assembler, and a linker. It
> was perfectly reasonable for K&R not to get into those details in the
> "Getting Started" section.
>
> The book isn't about teaching people how implementations work. It's
> about teaching people to program in C. Details about how the tools work
> are appropriately glossed over.

In "A Tour through the UNIX C Compiler" (D.M. Ritchie, Bell Laboratories,
reprinted in "Unix Programmer's Manual Volume 2 (c) 1979, 1983), Dennis
Ritchie makes it clear that said compiler's input was the output of a
separate C-language preprocessor, and that the compiler's ultimate output
was textual assembly language compatible with the Unix Assembler.

This situation is also described in "A Tour Through the Portable C Compiler"
(S.C. Johnson, Bell Laboratories, reprinted in the same "Unix Programmer's
Manual Volume 2), in a little more detail.
"The compiler consists of two passes, /pass1/ and /pass2/, that together
turn C source code into assembler code for the target machine. The two
passes are preceded by a preprocessor, that handles the #define and
#include statements, and related features (e.g. #ifdef, etc.). It is a
nearly machine independent program and will not be further discussed here.

The output of the preprocessor is a text file that is read as the standard
input of the first pass. ... The second pass produces, as standard output,
the desired assembler language source code."

It is worthy to note that, in "A Tour through the UNIX C Compiler", Dennis
Ritchie indicates that
"C was originally a one-pass compiler"
that they divided into two programs because of memory constraints. This explains
some of the early C language requirements, such as "declaration before use", etc.

[snip]

--
Lew Pitcher
"In Skills, We Trust"

On 31/07/2021 20:18, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:

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

Because it's plainly crazy.

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

So presumably that wasn't done with that libraylib_static.a library that
I used?

See, you don't have control over the libraries that other people distribute.

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

Hmm, yes it does, at least on x64 architecture.

A CALL to another function normally uses a relative offset. You can't
just extract functions and move them about without invalidating those
offsets. And doing that requires being able to precisely track what is
code and what is data (even in executable memory).

Another factor is being able to extract global variables, which are
usually accessed by absolute addresses. Put them somewhere else, and now
you /need/ relocation data to fix up all the references.

(DLL files will have that info, but are intended for moving the entirely
library, not individual blocks of functions or data.)

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

This is nonsense, at least for COFF files. Tell me whereabouts function
sizes are stored in that file format. It can only infer the sizes by
analysing the start addresses of all the functions, and then it might be
stuck on the last one, or where data is intermingled. That is too
haphazard an approach to use reliably.

David Brown creates applications for small devices so he has to pull out
all the stops, use all possible options to keep things compact.

But my desktop PC already has nearly 40,000 DLL files, totalling 25GB,
belong to the system or to installed programs.

If static linking of third party libraries was such a great idea, then I
would hardly ever see DLL files!

Archive files have lots of problems:

* Each library must issue them for multiple languages/compilers/formats
(raylib provides seprate versions for tcc and gcc, plus .dll that works
with anything)

* Each language implementation must come with 1000s of archive files for
misc libraries

* Any updates (breaking changes is a separate topic) means generating
multiple new versions, and updating every language installation that
bundles .a files

* Whether a smaller executable is actually achieved depends on how the
library vendor built the library

* If most of a library is used anyway, then multiple applications using
the same library will duplicate it on disk and in memory

DLLs solve a lot of those:

* The vendor provides one file that works with any compiler and any language

* No need to bundle with every compiler

* Only one copy of the library on any one machine

* Updates can benefit applications without recompiling or reinstalling

On 31/07/2021 20:32, Manfred wrote:
> On 7/31/2021 8:17 PM, Bart wrote:

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

To clarify, these options need to be applied to the library in question.

If it's a third party library, then presumably you have to depend on the
people creating the .a or .lib file to use suitable options.

(When I tried it on a small library, it more than doubled the size of
the size of the file.)

[big snip]

I've just installed TDM-GCC on my Windows 10 laptop.

There are two current installers, one based on MinGW.org (32 bits) and
one based on MinGW-w64 (64 bits). I tried both.

Quick summary: printf's "%zu" works correctly with both implementations
with default command-line arguments.

The 32-bit version generated an executable that does not appear to
depend on MSVCRT.DLL. It has the known problem with passing long double
arguments to printf. (The problem: gcc and Microsoft's runtime library
make different assumptions about how long double is represented. It's
not a bug either in gcc or in the runtime library; it's a bug in the way
they're combined into a C implementation. I believe that defining the
macro __USE_MINGW_ANSI_STDIO works around the problem. I haven't
confirmed that it works with the 32-bit TDD-GCC.

The 64-bit version handles "%zu" and long double correctly.
It generates an executable that *does* depend on msvcrt.dll.
I found that a little suprising.

TDM-GCC does not provide the "file" and "ldd" commands, so I used
the Cygwin versions to analyze the generated executable.

I don't know where either version found a printf implementation that
correctly handles "%zu". The copy of msvcrt.dll referred to by the
64-bit executable has a timestamp (Oct 16 2020) newer than when Windows
was installed, so it's not the copy that came with Windows. I don't
know where it came from. Is it possible that newer versions of
msvcrt.dll implement "%zu"?

(To be clear, Bart, I am not saying you should care about "%zu",
nor am I suggesting that you should abandon Windows.)

Here's a log from the 32-bit version:
========================================
C:\cygwin64\home\kst\tdm>type c.c
#include <stdio.h>
int main(void) {
double x = 1.0/3.0;
long double xx = 1.0L/3.0L;
printf("sizeof (void*) = %zu", sizeof (void*));
printf(" (expected %d)\n", (int)sizeof (void*));
printf("long double x = %Lg", xx);
printf(" (expected %g)\n", x);
}

C:\cygwin64\home\kst\tdm>gcc --version
gcc (tdm-1) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

C:\cygwin64\home\kst\tdm>gcc c.c -o c.exe & .\c.exe
sizeof (void*) = 4 (expected 4)
long double x = -3.72066e-103 (expected 0.333333)

C:\cygwin64\home\kst\tdm>C:\cygwin64\bin\file c.exe
c.exe: PE32 executable (console) Intel 80386, for MS Windows

C:\cygwin64\home\kst\tdm>C:\cygwin64\bin\ldd c.exe
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff992ad0000)
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x76ee0000)
wow64.dll => /cygdrive/c/WINDOWS/System32/wow64.dll (0x7ff991600000)
wow64win.dll => /cygdrive/c/WINDOWS/System32/wow64win.dll (0x7ff991230000)

C:\cygwin64\home\kst\tdm>
========================================

Here's a log from the 64-bit version:
========================================
C:\cygwin64\home\kst\tdm>type c.c
#include <stdio.h>
int main(void) {
double x = 1.0/3.0;
long double xx = 1.0L/3.0L;
printf("sizeof (void*) = %zu", sizeof (void*));
printf(" (expected %d)\n", (int)sizeof (void*));
printf("long double x = %Lg", xx);
printf(" (expected %g)\n", x);
}

C:\cygwin64\home\kst\tdm>gcc --version
gcc (tdm64-1) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

C:\cygwin64\home\kst\tdm>gcc c.c -o c.exe & .\c.exe
sizeof (void*) = 8 (expected 8)
long double x = 0.333333 (expected 0.333333)

C:\cygwin64\home\kst\tdm>C:\cygwin64\bin\file c.exe
c.exe: PE32+ executable (console) x86-64, for MS Windows

C:\cygwin64\home\kst\tdm>C:\cygwin64\bin\ldd c.exe
ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff992ad0000)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff991fe0000)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff990210000)
msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll (0x7ff992100000)

C:\cygwin64\home\kst\tdm>
========================================

--
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 8/1/2021 12:10 AM, Bart wrote:
> On 31/07/2021 20:32, Manfred wrote:
>> On 7/31/2021 8:17 PM, Bart wrote:
>
>>> 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.
>
> To clarify, these options need to be applied to the library in question.
>
> If it's a third party library, then presumably you have to depend on the
> people creating the .a or .lib file to use suitable options.

Yes, as I wrote earlier, this feature requires the cooperation of the
compiler with the linker, if the compiler was not instructed to generate
the library code accordingly, you are stuck with object module
granularity (as per your earlier findings - I didn't check)

>
> (When I tried it on a small library, it more than doubled the size of
> the size of the file.)
>
>

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [big snip]
>
> I've just installed TDM-GCC on my Windows 10 laptop.
[big snip]

I've just done a similar experiment with tcc, installed on Windows 10
from

http://download.savannah.gnu.org/releases/tinycc/tcc-0.9.27-win64-bin.zip

There's a win32 installer as well. I didn't try it.

Using the same program from my previous post and compiling with default
options ("tcc c.c"), both "%zu" and "%Lg" work correctly.

The lcc-generated executable is a "PE32+ executable (console) x86-64
(stripped to external PDB), for MS Windows".

Running Cygwin "ldd" on the executable shows:

ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff992ad0000)
KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff991fe0000)
KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff990210000)
msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll (0x7ff992100000)

--
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 7/31/21 3:10 PM, Bart wrote:
> On 31/07/2021 20:32, Manfred wrote:
>> On 7/31/2021 8:17 PM, Bart wrote:
>
>>> 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.
>
> To clarify, these options need to be applied to the library in question.
>
> If it's a third party library, then presumably you have to depend on the
> people creating the .a or .lib file to use suitable options.
>
> (When I tried it on a small library, it more than doubled the size of
> the size of the file.)
>

Yes, to generate the information to allow selective linking adds a lot
of meta-data to the object files.

That is one reason it normally isn't the default for the compiler, as it
assumes that most files being compiled don't have a lot of 'unused'
code, so there is no need to generate all the extra meta-data to allow
partial linking of the files.

On 31/07/2021 23:48, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [big snip]
>>
>> I've just installed TDM-GCC on my Windows 10 laptop.
> [big snip]
>
> I've just done a similar experiment with tcc, installed on Windows 10
> from
>
> http://download.savannah.gnu.org/releases/tinycc/tcc-0.9.27-win64-bin.zip
>
> There's a win32 installer as well. I didn't try it.
>
> Using the same program from my previous post and compiling with default
> options ("tcc c.c"), both "%zu" and "%Lg" work correctly.
>
> The lcc-generated executable is a "PE32+ executable (console) x86-64
> (stripped to external PDB), for MS Windows".

You mean tcc rather than lcc?

I downloaded this exact version with these results:

--------------------------------------
C:\tcc>dir
....
01/08/2021 00:08 <DIR> .
01/08/2021 00:08 <DIR> ..
01/08/2021 00:04 <DIR> doc
01/08/2021 00:04 <DIR> examples
31/07/2021 02:12 86 hello.c
01/08/2021 00:06 2,048 hello.exe
01/08/2021 00:04 155,136 i386-win32-tcc.exe
01/08/2021 00:04 <DIR> include
01/08/2021 00:08 2,463 kkk1
01/08/2021 00:04 <DIR> lib
01/08/2021 00:04 <DIR> libtcc
01/08/2021 00:04 156,160 libtcc.dll
01/08/2021 00:04 23,552 tcc.exe
....

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

C:\tcc>tcc hello.c

C:\tcc>hello
Hello, World! zu

This was on Windows 7, but my last test on W10 didn't fix anything so I
doubt it would here.

The EXE files shows it specifically imports printf() from msvcrt.dll

Bart <bc@freeuk.com> writes:
> On 31/07/2021 23:48, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> [big snip]
>>>
>>> I've just installed TDM-GCC on my Windows 10 laptop.
>> [big snip]
>> I've just done a similar experiment with tcc, installed on Windows
>> 10
>> from
>> http://download.savannah.gnu.org/releases/tinycc/tcc-0.9.27-win64-bin.zip
>> There's a win32 installer as well. I didn't try it.
>> Using the same program from my previous post and compiling with
>> default
>> options ("tcc c.c"), both "%zu" and "%Lg" work correctly.
>> The lcc-generated executable is a "PE32+ executable (console) x86-64
>> (stripped to external PDB), for MS Windows".
>
> You mean tcc rather than lcc?

Yes, thank you, that was a typo.

> I downloaded this exact version with these results:
>
> --------------------------------------
> C:\tcc>dir
> ...
> 01/08/2021 00:08 <DIR> .
> 01/08/2021 00:08 <DIR> ..
> 01/08/2021 00:04 <DIR> doc
> 01/08/2021 00:04 <DIR> examples
> 31/07/2021 02:12 86 hello.c
> 01/08/2021 00:06 2,048 hello.exe
> 01/08/2021 00:04 155,136 i386-win32-tcc.exe
> 01/08/2021 00:04 <DIR> include
> 01/08/2021 00:08 2,463 kkk1
> 01/08/2021 00:04 <DIR> lib
> 01/08/2021 00:04 <DIR> libtcc
> 01/08/2021 00:04 156,160 libtcc.dll
> 01/08/2021 00:04 23,552 tcc.exe
> ...
>
> C:\tcc>type hello.c
> #include <stdio.h>
> int main(void) {
> printf("Hello, World! %zu\n", sizeof(int));
> }
>
> C:\tcc>tcc hello.c
>
> C:\tcc>hello
> Hello, World! zu
>
>
> This was on Windows 7, but my last test on W10 didn't fix anything so
> I doubt it would here.

Results on your Windows 10 system could be interesting.

> The EXE files shows it specifically imports printf() from msvcrt.dll

OK, so it works correctly on my system but not on yours. I'll note that
I've seen multiple versions of msvcrt.dll in different directories on my
system (different sizes, different timestamps). Either my msvcrt.dll
implements %zu correctly, or tcc and tdm-gcc generate executables that
use something other than msvcrt.dll to implement printf.

This discussion was triggered by your statement that %zu "doesn't work
on Windows". It clearly does, though it might sometimes fail for
reasons that are not clear. I do not expect you to acknowledge that
your original statement was false.

--
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 01/08/2021 00:14, Bart wrote:
> On 31/07/2021 23:48, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> [big snip]
>>>
>>> I've just installed TDM-GCC on my Windows 10 laptop.
>> [big snip]
>>
>> I've just done a similar experiment with tcc, installed on Windows 10
>> from
>>
>>
>> http://download.savannah.gnu.org/releases/tinycc/tcc-0.9.27-win64-bin.zip
>>
>> There's a win32 installer as well.  I didn't try it.
>>
>> Using the same program from my previous post and compiling with default
>> options ("tcc c.c"), both "%zu" and "%Lg" work correctly.
>>
>> The lcc-generated executable is a "PE32+ executable (console) x86-64
>> (stripped to external PDB), for MS Windows".

You might try also this compiler:

https://github.com/sal55/langs/blob/master/bcc.exe

Run as:

bcc hello.c

This relies 100% on Windows' msvcrt.dll to do printf.

Bart <bc@freeuk.com> writes:
> On 01/08/2021 00:14, Bart wrote:
>> On 31/07/2021 23:48, Keith Thompson wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>> [big snip]
>>>>
>>>> I've just installed TDM-GCC on my Windows 10 laptop.
>>> [big snip]
>>>
>>> I've just done a similar experiment with tcc, installed on Windows 10
>>> from
>>>
>>> http://download.savannah.gnu.org/releases/tinycc/tcc-0.9.27-win64-bin.zip
>>>
>>> There's a win32 installer as well.  I didn't try it.
>>>
>>> Using the same program from my previous post and compiling with default
>>> options ("tcc c.c"), both "%zu" and "%Lg" work correctly.
>>>
>>> The lcc-generated executable is a "PE32+ executable (console) x86-64
>>> (stripped to external PDB), for MS Windows".
[correction: tcc-generated]

> You might try also this compiler:
>
> https://github.com/sal55/langs/blob/master/bcc.exe
>
> Run as:
>
> bcc hello.c
>
> This relies 100% on Windows' msvcrt.dll to do printf.

This version of C:\cygwin64\home\kst\bcc\bcc.exe is not compatible
with the version of Windows you're running. Check your computer's
system information and then contact the software publisher.

A popup error message (which I can't copy and paste) says "Unsupported
16-Bit Application".

--
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:
> On 31/07/2021 20:18, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
>
> > 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.
>
> So presumably that wasn't done with that libraylib_static.a library that
> I used?

Possibly. As I wrote, there are traps and even if you use
proper compiler and linker options the result may be disappointing.

> See, you don't have control over the libraries that other people distribute.
>
>
> > 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.
>
> Hmm, yes it does, at least on x64 architecture.
>
> A CALL to another function normally uses a relative offset. You can't
> just extract functions and move them about without invalidating those
> offsets. And doing that requires being able to precisely track what is
> code and what is data (even in executable memory).

Do you know what position-independent code means? And what static
linking means? With static linking relative positions of various
parts of executable are fixed at link time. Frequently also
absolute positions are fixed at link time, but for example DOS
exe format contained relocation info so absolute positions were
fixed only at load time. And yes, after static linking linking
you can not move code around, unless (like DOS) you keep
relocation tables. During link you use relocation tables, so
linker moves sections around and adjusts addresses using
relocation tables.

FYI, position-idependent code is different: after link you
get a blob which uses only relative addresses inside blob.
If for some reason relative addressing is inadeqater (say
machine does not support PC-relative addressing mode),
then position-idependent code uses extra register containing
its location in memory. So for internal references you can
put the blob anywhere in address space and it will work the
same. There is trouble with external references. External
references are all replaced by indirect references via a
table. This table is filled by dynamic linker, based on
_dynamic_ relocation tables. Table of external references
is usually much smaller than code, so gain with
position-idependent independent code is that you can keep
one copy of executable part in memory and use it for
many programs (variables and table of external references
are separate in each program). You need position-idependent
code when you want shared libraries or dynamic linking
without upleasent restrictions. Main point here is that
for sane sharing you do not want to touch executable
part of library, so you can not do relocations on load.

With static linking addresses are fixed, either after
link proper or after applying relocations (which
modifies code). Since addresses are fixed there
is no need for position-idependent code.

> Another factor is being able to extract global variables, which are
> usually accessed by absolute addresses. Put them somewhere else, and now
> you /need/ relocation data to fix up all the references.

With static linking addresses are known when whole linking process
is finished (logically on DOS linking process is finshed only
after load). In particular after linking proces you no longer can
"Put them somewhere else". Relative addresses of global variables
can not change after link proper, on Linux also absolute addresses
can not change after link.

> (DLL files will have that info, but are intended for moving the entirely
> library, not individual blocks of functions or data.)

Yes, Windows i386 DLL-s used static linking with relocation info
for adjusting start address of library at load time. And relocation
was applied to the whole library. This is very unlike what ELF
on Linux is doing: Linux shared libraries need position-independent
code, unlike i386 Windows DLL-s. IIUC also 64-bit Windows DLL
work like Linux ones and need 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...
>
> This is nonsense, at least for COFF files. Tell me whereabouts function
> sizes are stored in that file format. It can only infer the sizes by
> analysing the start addresses of all the functions, and then it might be
> stuck on the last one, or where data is intermingled.

I do not understand your fixation on function size. Linker works
with sections and relocates sections as a whole. If you want
functions than use '-ffunction-sections', then section size
will be the same as function size. Concerning COFF, I do not
know if it supports multiple sections in single .o (or .obj if
you prefer) file. If not, then we are back to splitting files
so that single .o file contains exactly one function. I would
hope that Windows COFF (there are a lot of variants of COFF,
but you probably only care about Windows) adapted to modern
trends, but I had no reason to check this.

Bottom lines is that linker works on section, which in primitive
systems may be limited to whole .o file. Each section contains
table of exported addresses, imported ones and table of needed
relocations. Linker moves _sections_ (that is why without
'-ffunction-sections' (explicit or possibly as default for some
target) linker can not eliminate part of section, this is all
-or-nothing business.

> That is too
> haphazard an approach to use reliably.

Well, for reliable results one do not use random binary libraries
from Internet. One either fetches sources and compiles them
with needed options or at least inspects binaries (objdump -h
will tell you which sections are in a library). For example,
when I created file containing 3 functions and compiled it
using '-ffunction-sections' I get from objedump:

.....
3 .text.f_id 00000003 0000000000000000 0000000000000000 00000040 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .text.f_a1 00000003 0000000000000000 0000000000000000 00000043 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .text.f_a2 00000003 0000000000000000 0000000000000000 00000046 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
.....

so there are 3 sections, 1 for each function. When I omit
'-ffunction-sections' I get

0 .text 00000009 0000000000000000 0000000000000000 00000040 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
.....

that is single code section.

> David Brown creates applications for small devices so he has to pull out
> all the stops, use all possible options to keep things compact.
>
> But my desktop PC already has nearly 40,000 DLL files, totalling 25GB,
> belong to the system or to installed programs.
>
> If static linking of third party libraries was such a great idea, then I
> would hardly ever see DLL files!

On 01/08/2021 00:25, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 31/07/2021 23:48, Keith Thompson wrote:

>> This was on Windows 7, but my last test on W10 didn't fix anything so
>> I doubt it would here.
>
> Results on your Windows 10 system could be interesting.

Yeah. On the blue W10 laptop, it didn't work. On the purple one, it did.

msvcrt.dll on the blue one is dated 2016; on the purple, 2019.

(I didn't have much luck copying the 'good' msvcrt.dll to my W7 PC, but
it needs a better attempt.)

> This discussion was triggered by your statement that %zu "doesn't work
> on Windows". It clearly does, though it might sometimes fail for
> reasons that are not clear. I do not expect you to acknowledge that
> your original statement was false.

OK, it doesn't when msvcrt.dll is too old.

Although I don't really distribute programs anymore, it is conceivable
that not everyone will have the very latest libraries, not more than a
couple of years old. /I/ don't!

So I still don't intend using that feature. (When no-one's looking, I
naughtily just use "%d". On Win64 it's not a problem, it will just
ignore the high word. Unless sizeof actually yields value above 2GB.)

On 01/08/2021 00:50, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 01/08/2021 00:14, Bart wrote:
>>> On 31/07/2021 23:48, Keith Thompson wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> [big snip]
>>>>>
>>>>> I've just installed TDM-GCC on my Windows 10 laptop.
>>>> [big snip]
>>>>
>>>> I've just done a similar experiment with tcc, installed on Windows 10
>>>> from
>>>>
>>>> http://download.savannah.gnu.org/releases/tinycc/tcc-0.9.27-win64-bin.zip
>>>>
>>>> There's a win32 installer as well.  I didn't try it.
>>>>
>>>> Using the same program from my previous post and compiling with default
>>>> options ("tcc c.c"), both "%zu" and "%Lg" work correctly.
>>>>
>>>> The lcc-generated executable is a "PE32+ executable (console) x86-64
>>>> (stripped to external PDB), for MS Windows".
> [correction: tcc-generated]
>
>> You might try also this compiler:
>>
>> https://github.com/sal55/langs/blob/master/bcc.exe
>>
>> Run as:
>>
>> bcc hello.c
>>
>> This relies 100% on Windows' msvcrt.dll to do printf.
>
> This version of C:\cygwin64\home\kst\bcc\bcc.exe is not compatible
> with the version of Windows you're running. Check your computer's
> system information and then contact the software publisher.
>
> A popup error message (which I can't copy and paste) says "Unsupported
> 16-Bit Application".
>

OK, if the size of bcc.exe is 1,046,016 then it's a puzzle. If a bit
smaller, it might be corrupted. In either case, never mind.

(I no longer have up-to-date generated-C versions as an alternative.)

Dump of bcc.exe; Size = 1046016 bytes
0000: 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00 MZ..............
0010: b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 ........@.......
0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030: 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 ................
0040: 0e 1f ba 0e 00 b4 09 cd 21 b8 01 4c cd 21 54 68 ........!..L.!Th
0050: 69 73 20 70 72 6f 67 72 61 6d 20 63 61 6e 6e 6f is program canno
0060: 74 20 62 65 20 72 75 6e 20 69 6e 20 44 4f 53 20 t be run in DOS
0070: 6d 6f 64 65 2e 0d 0d 0a 24 00 00 00 00 00 00 00 mode....$.......
0080: 50 45 00 00 64 86 04 00 00 00 00 00 00 00 00 00 PE..d...........
0090: 00 00 00 00 f0 00 2f 02 0b 02 01 00 00 e8 03 00 ....../.........
00a0: 00 0a 0c 00 00 e2 42 00 00 a6 03 00 00 10 00 00 ......B.........
00b0: 00 00 40 00 00 00 00 00 00 10 00 00 00 02 00 00 ..@.............
00c0: 04 00 00 00 00 00 00 00 05 00 02 00 00 00 00 00 ................
00d0: 00 00 53 00 00 04 00 00 00 00 00 00 03 00 00 00 ..S.............
00e0: 00 00 40 00 00 00 00 00 00 00 20 00 00 00 00 00 ..@....... .....
00f0: 00 00 10 00 00 00 00 00 00 10 00 00 00 00 00 00 ................
0100: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 ................

On 01/08/2021 00:51, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:

>> A CALL to another function normally uses a relative offset. You can't
>> just extract functions and move them about without invalidating those
>> offsets. And doing that requires being able to precisely track what is
>> code and what is data (even in executable memory).
>
> Do you know what position-independent code means?

I know what I mean by it. Which is the ability to relocate a contiguous
block of code at any address, and internal references /within/ the code
still work. But not to move parts of it separately.

(I think this was discussed on comp.lang.misc recently.)

> And what static
> linking means?

In the current context, whether an external library's code is
incorporated into the executable you're building. Otherwise it's
accessed as a shared library with fixups done when the program is loaded
for execution.

>> (DLL files will have that info, but are intended for moving the entirely
>> library, not individual blocks of functions or data.)
>
> Yes, Windows i386 DLL-s used static linking with relocation info
> for adjusting start address of library at load time. And relocation
> was applied to the whole library. This is very unlike what ELF
> on Linux is doing: Linux shared libraries need position-independent
> code, unlike i386 Windows DLL-s. IIUC also 64-bit Windows DLL
> work like Linux ones and need position-independent code.

Actually there is no such restriction on 64-bit DLLs. The only
requirement is that absolute addresses within the code are part of the
relocation table. (At least, /I/ don't bother with PIC, it's all mixed,
and the DLL files I write seem to work.)

>> This is nonsense, at least for COFF files. Tell me whereabouts function
>> sizes are stored in that file format. It can only infer the sizes by
>> analysing the start addresses of all the functions, and then it might be
>> stuck on the last one, or where data is intermingled.
>
> I do not understand your fixation on function size. Linker works
> with sections and relocates sections as a whole. If you want
> functions than use '-ffunction-sections', then section size
> will be the same as function size.

So one section per function, really?

I remember linkers on mainframes being massive programs taking most of
the resources, and taking forever.

When I created my own linkers (I just called them loaders), they were
much, much simpler, and worked instantly. They just incorporated every
module submitted. This worked well even with 64KB memory. But probably
because /I/ wrote all the libraries so they weren't bloated! (It did
manage overlays though.)

Now I've eliminated most aspects of 'linking' completely. I don't use
object files nor these ".a" or ".lib" files, which to me seem so
old-fashioned.

> Concerning COFF, I do not
> know if it supports multiple sections in single .o (or .obj if
> you prefer) file.

I think they use 16-bit fields for section numbers, so maybe 32K or 64K
sections. Whether supported by tools is another matter.

> If not, then we are back to splitting files
> so that single .o file contains exactly one function. I would
> hope that Windows COFF (there are a lot of variants of COFF,
> but you probably only care about Windows) adapted to modern
> trends, but I had no reason to check this.

> Bottom lines is that linker works on section, which in primitive
> systems may be limited to whole .o file.

(Whenever I sometimes generate .obj, it actually represents an entire
program. So rather than one function per .o instead one one module, it's
one program per .o! My aims are the opposite.)

>> David Brown creates applications for small devices so he has to pull out
>> all the stops, use all possible options to keep things compact.
>>
>> But my desktop PC already has nearly 40,000 DLL files, totalling 25GB,
>> belong to the system or to installed programs.
>>
>> If static linking of third party libraries was such a great idea, then I
>> would hardly ever see DLL files!
>
> I do not advocate using static linking, but in some (rare) situations
> it can be helpful. Cretainly not a normal approach on desktop system.

>>
>> Archive files have lots of problems:
>>
>> * Each library must issue them for multiple languages/compilers/formats
>> (raylib provides seprate versions for tcc and gcc, plus .dll that works
>> with anything)
>
> That is independent issue having little to do with static versus
> dynamic. If you "standarize" on "one true toolchain" than you
> can use single format. OTOH, AFAIK you can install alternative
> DLL loaders in Windows, so if you wish you can have as many
> dll formats as you wish.

For quite a while I wondered why compilers still /bothered/ with .a and
..lib files, when many can now link directly with .dll.

(I think someone once suggested that functions in dll files could be
individually extracted, but for the reasons being discussed, that is not
practical. Why they'd want that is another question.)

Bart <bc@freeuk.com> writes:
> On 01/08/2021 00:50, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
[...]
>>> You might try also this compiler:
>>>
>>> https://github.com/sal55/langs/blob/master/bcc.exe
>>>
>>> Run as:
>>>
>>> bcc hello.c
>>>
[...]
>> A popup error message (which I can't copy and paste) says
>> "Unsupported 16-Bit Application".
>
> OK, if the size of bcc.exe is 1,046,016 then it's a puzzle. If a bit
> smaller, it might be corrupted. In either case, never mind.

My mistake, I assumed I could download it directly from that URL and got
an HTML file (and didn't check its contents).

The executable is 1046016 bytes. It would't compile my test program
because it apparently treats "long double" as a syntax error. After
I commented out that part of it, the compiled program handles "%zu"
correctly.

[...]

--
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 */

In article <87r1fe9dwb.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Bart <bc@freeuk.com> writes:
>> On 01/08/2021 00:50, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>[...]
>>>> You might try also this compiler:
>>>>
>>>> https://github.com/sal55/langs/blob/master/bcc.exe

As I'm sure you figured out, you have to change "blob" to "raw" in the
above URL to make it fetchable with, e.g., "wget" (or "curl", etc)

>>> A popup error message (which I can't copy and paste) says
>>> "Unsupported 16-Bit Application".
....
>My mistake, I assumed I could download it directly from that URL and got
>an HTML file (and didn't check its contents).

--
I've learned that people will forget what you said, people will forget
what you did, but people will never forget how you made them feel.

- Maya Angelou -

On 01/08/2021 02:38, Kenny McCormack wrote:
> In article <87r1fe9dwb.fsf@nosuchdomain.example.com>,
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 01/08/2021 00:50, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> You might try also this compiler:
>>>>>
>>>>> https://github.com/sal55/langs/blob/master/bcc.exe
>
> As I'm sure you figured out, you have to change "blob" to "raw" in the
> above URL to make it fetchable with, e.g., "wget" (or "curl", etc)

I don't normally put binaries on github (I don't think they encourage
it; it's supposed to be for source code).

But I tested it by clicking on 'Download'.

On 01/08/2021 02:01, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 01/08/2021 00:50, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
> [...]
>>>> You might try also this compiler:
>>>>
>>>> https://github.com/sal55/langs/blob/master/bcc.exe
>>>>
>>>> Run as:
>>>>
>>>> bcc hello.c
>>>>
> [...]
>>> A popup error message (which I can't copy and paste) says
>>> "Unsupported 16-Bit Application".
>>
>> OK, if the size of bcc.exe is 1,046,016 then it's a puzzle. If a bit
>> smaller, it might be corrupted. In either case, never mind.
>
> My mistake, I assumed I could download it directly from that URL and got
> an HTML file (and didn't check its contents).
>
> The executable is 1046016 bytes. It would't compile my test program
> because it apparently treats "long double" as a syntax error. After
> I commented out that part of it, the compiled program handles "%zu"
> correctly.

That's a surprise, long double should work (but treats it as double):

C:\c>type c.c
#include <stdio.h>

int main(void) {
printf("sizeof = %d\n", (int)sizeof(long double));
}

C:\c>bcc c
Compiling c.c to c.exe

C:\c>c
sizeof = 8

C:\c>

(Lots and lots of things don't work properly, as I've found over the
last 4 years, so the product is for private use.

I may get around to a new front-end at some point, to go with a new
back-end I'm developing now for general use.)

> The executable is 1046016 bytes.

(The actual compiler is 380KB, the rest is headers, mostly windows.h.
You can see the internal headers with 'bcc -writeheaders' which writes
them as .hdr files to the current directory.)

On 01/08/2021 11:54, Bart wrote:
> On 01/08/2021 02:01, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 01/08/2021 00:50, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>>> You might try also this compiler:
>>>>>
>>>>> https://github.com/sal55/langs/blob/master/bcc.exe
>>>>>
>>>>> Run as:
>>>>>
>>>>>      bcc hello.c
>>>>>
>> [...]
>>>> A popup error message (which I can't copy and paste) says
>>>> "Unsupported 16-Bit Application".
>>>
>>> OK, if the size of bcc.exe is 1,046,016 then it's a puzzle. If a bit
>>> smaller, it might be corrupted. In either case, never mind.
>>
>> My mistake, I assumed I could download it directly from that URL and got
>> an HTML file (and didn't check its contents).
>>
>> The executable is 1046016 bytes.  It would't compile my test program
>> because it apparently treats "long double" as a syntax error.  After
>> I commented out that part of it, the compiled program handles "%zu"
>> correctly.
>
>
> That's a surprise, long double should work (but treats it as double):

Assuming it's the program you posted previously, the problem was the 'L'
here:

1.0L

There are two handlers for float literals, one using strtod() for base
10, the other for other bases, which omitted support for 'L'. The strtod
version was temporarily commented out. Now both support 'L' (ie. ignore it).

On 8/1/21 12:29 AM, Keith Thompson wrote:
> [big snip]
>
> I've just installed TDM-GCC on my Windows 10 laptop.
>
> There are two current installers, one based on MinGW.org (32 bits) and
> one based on MinGW-w64 (64 bits). I tried both.
>
> Quick summary: printf's "%zu" works correctly with both implementations
> with default command-line arguments.
>
> The 32-bit version generated an executable that does not appear to
> depend on MSVCRT.DLL. It has the known problem with passing long double
> arguments to printf. (The problem: gcc and Microsoft's runtime library
> make different assumptions about how long double is represented. It's
> not a bug either in gcc or in the runtime library; it's a bug in the way
> they're combined into a C implementation. I believe that defining the
> macro __USE_MINGW_ANSI_STDIO works around the problem. I haven't
> confirmed that it works with the 32-bit TDD-GCC.
>
> The 64-bit version handles "%zu" and long double correctly.
> It generates an executable that *does* depend on msvcrt.dll.
> I found that a little suprising.

It is also surprising that the generated 32-bit executable references
dll's both from System32 and SysWOW64.

>
> TDM-GCC does not provide the "file" and "ldd" commands, so I used
> the Cygwin versions to analyze the generated executable.
>
> I don't know where either version found a printf implementation that
> correctly handles "%zu". The copy of msvcrt.dll referred to by the
> 64-bit executable has a timestamp (Oct 16 2020) newer than when Windows
> was installed, so it's not the copy that came with Windows. I don't
> know where it came from.
Probably from the "lovely" Windows Update? (© Waldek Hebisch)

Is it possible that newer versions of
> msvcrt.dll implement "%zu"?

My Win10 box has a msvcrt.dll whose printf implements "%zu" as well.
However, Microsoft ships other dll's that export their own printf.
Notable examples are runtime libs that ship with applications developed
with relatively recent versions of Visual Studio.

I still have a copy of MSVC 5.0, and I verified that msvcrt.dll was
indeed the redistributable Microsoft C runtime that came with that
product - keyword here being "Microsoft", i.e. /their/ implementation of
C, and not intended to be used by applications other than those
developed with VisualC++. More recent versions (I'd say those from the
current century) moved to msvcrXXX.dll + others.

>
> (To be clear, Bart, I am not saying you should care about "%zu",
> nor am I suggesting that you should abandon Windows.)
>
> Here's a log from the 32-bit version:
> ========================================
> C:\cygwin64\home\kst\tdm>type c.c
> #include <stdio.h>
> int main(void) {
> double x = 1.0/3.0;
> long double xx = 1.0L/3.0L;
> printf("sizeof (void*) = %zu", sizeof (void*));
> printf(" (expected %d)\n", (int)sizeof (void*));
> printf("long double x = %Lg", xx);
> printf(" (expected %g)\n", x);
> }
>
> C:\cygwin64\home\kst\tdm>gcc --version
> gcc (tdm-1) 10.3.0
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> C:\cygwin64\home\kst\tdm>gcc c.c -o c.exe & .\c.exe
> sizeof (void*) = 4 (expected 4)
> long double x = -3.72066e-103 (expected 0.333333)
>
> C:\cygwin64\home\kst\tdm>C:\cygwin64\bin\file c.exe
> c.exe: PE32 executable (console) Intel 80386, for MS Windows
>
> C:\cygwin64\home\kst\tdm>C:\cygwin64\bin\ldd c.exe
> ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff992ad0000)
> ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x76ee0000)
> wow64.dll => /cygdrive/c/WINDOWS/System32/wow64.dll (0x7ff991600000)
> wow64win.dll => /cygdrive/c/WINDOWS/System32/wow64win.dll (0x7ff991230000)
>
> C:\cygwin64\home\kst\tdm>
> ========================================
>
> Here's a log from the 64-bit version:
> ========================================
> C:\cygwin64\home\kst\tdm>type c.c
> #include <stdio.h>
> int main(void) {
> double x = 1.0/3.0;
> long double xx = 1.0L/3.0L;
> printf("sizeof (void*) = %zu", sizeof (void*));
> printf(" (expected %d)\n", (int)sizeof (void*));
> printf("long double x = %Lg", xx);
> printf(" (expected %g)\n", x);
> }
>
> C:\cygwin64\home\kst\tdm>gcc --version
> gcc (tdm64-1) 10.3.0
> Copyright (C) 2020 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> C:\cygwin64\home\kst\tdm>gcc c.c -o c.exe & .\c.exe
> sizeof (void*) = 8 (expected 8)
> long double x = 0.333333 (expected 0.333333)
>
> C:\cygwin64\home\kst\tdm>C:\cygwin64\bin\file c.exe
> c.exe: PE32+ executable (console) x86-64, for MS Windows
>
> C:\cygwin64\home\kst\tdm>C:\cygwin64\bin\ldd c.exe
> ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff992ad0000)
> KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL (0x7ff991fe0000)
> KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll (0x7ff990210000)
> msvcrt.dll => /cygdrive/c/WINDOWS/System32/msvcrt.dll (0x7ff992100000)
>
> C:\cygwin64\home\kst\tdm>
> ========================================
>

In article <se5tp1$ruk$1@dont-email.me>, Bart <bc@freeuk.com> wrote:
>On 01/08/2021 02:38, Kenny McCormack wrote:
>> In article <87r1fe9dwb.fsf@nosuchdomain.example.com>,
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 01/08/2021 00:50, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>>>> You might try also this compiler:
>>>>>>
>>>>>> https://github.com/sal55/langs/blob/master/bcc.exe
>>
>> As I'm sure you figured out, you have to change "blob" to "raw" in the
>> above URL to make it fetchable with, e.g., "wget" (or "curl", etc)
>
>I don't normally put binaries on github (I don't think they encourage
>it; it's supposed to be for source code).
>
>But I tested it by clicking on 'Download'.

Given the problem that Keith reported (ending up with an HTML file instead
of a binary executable), I assumed he had used something like wget (or
curl) on the URL you provided. That would, indeed, just fetch some
(useless) HTML.

As noted above, changing "blob" to "raw" will give you a URL that you can
then wget and it will get you what you want.

Like Keith, I try to avoid using GUI web browsers with github. I just get
stuff with wget.

--
It's possible that leasing office space to a Starbucks is a greater liability
in today's GOP than is hitting your mother on the head with a hammer.

Bart <bc@freeuk.com> writes:
> On 01/08/2021 11:54, Bart wrote:
>> On 01/08/2021 02:01, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 01/08/2021 00:50, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>>>> You might try also this compiler:
>>>>>>
>>>>>> https://github.com/sal55/langs/blob/master/bcc.exe
>>>>>>
>>>>>> Run as:
>>>>>>
>>>>>>      bcc hello.c
>>>>>>
>>> [...]
>>>>> A popup error message (which I can't copy and paste) says
>>>>> "Unsupported 16-Bit Application".
>>>>
>>>> OK, if the size of bcc.exe is 1,046,016 then it's a puzzle. If a bit
>>>> smaller, it might be corrupted. In either case, never mind.
>>>
>>> My mistake, I assumed I could download it directly from that URL and got
>>> an HTML file (and didn't check its contents).
>>>
>>> The executable is 1046016 bytes.  It would't compile my test program
>>> because it apparently treats "long double" as a syntax error.  After
>>> I commented out that part of it, the compiled program handles "%zu"
>>> correctly.
>>
>> That's a surprise, long double should work (but treats it as double):
>
> Assuming it's the program you posted previously, the problem was the
> 'L' here:
>
> 1.0L
>
> There are two handlers for float literals, one using strtod() for base
> 10, the other for other bases, which omitted support for 'L'. The
> strtod version was temporarily commented out. Now both support 'L'
> (ie. ignore it).

Yes, it was the "L" suffix.

If you care about conformance, giving double and long double the same
size and representation is valid, but they're still distinct types.
For example, a conforming C compiler must issue a diagnostic for:

double *p1 = 0;
long double *p2 = p1;

(If you don't care about conformance, there's no need to say so.)

--
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 */