On 1/9/2024 9:28 PM, Kaz Kylheku wrote:
> On 2024-01-10, tTh <tth@none.invalid> wrote:
>> On 1/10/24 01:40, Bart wrote:
>>> An easy compiler is one where you just do:
>>>
>>>    gcc prog
>>>
>>> and not, at the very least:
>>>
>>>    gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>
>>> Meanwhile I routinely test C programs on half a dozen compilers. I can't
>>> be bothered with all this crap.
>>
>> So do as all of us do : put this crap in a Makefile or
>> a shell script, and forget about it.
>
> Please don't get Bart started on makefiles!
>

Don't get me started about freaking out for some minutes when I failed
to use a god damn tab! My makefile would not work. God damn it! Ahhhh,
that was around 20 years ago.

On 09/01/2024 23:22, Bart wrote:
> On 09/01/2024 21:55, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>
>>> Which version of C do you suggest; the one where:
>>>
>>>    #include <stdio.h>
>>>
>>>    int main(void) {
>>>        int A[0];
>>>        int B[]={};
>>>
>>>        printf("%zu\n", sizeof(A));
>>>        printf("%zu\n", sizeof(B));
>>>    }
>>>
>>> compiles fine with tcc, gcc and clang, and displays 0 for the sizes?
>>>
>>> Or the one where those produce warnings? Or the one where it actually
>>> fails?
>>
>> All of them.  You've been told over, and over, and over.
>
> Been told what? That I should produce a compiler that, at anyone's whim,
> can either pass, fail or warn about the same piece of code?

No, you have been told:

1. C is a language defined by the standards. Without further
qualification, "C" refers to the latest published ISO standard -
currently C17. But it's also fine to refer to specific standards, such
as C99. The standards define the language syntax, constraints, required
diagnostics (implementations are free to choose warnings or hard
errors), and standard library specifications. There are also many
pre-standard C versions, for which "K&R C" is /almost/ a standard.

2. Almost all C compilers implement some extensions by default. These
extensions are not C, but are compiler-specific language variants. Some
people find them useful, other people prefer to stick to standard C.
Some extensions are so widely implemented that they may be considered a
pseudo-standard, others are very compiler or target specific.

3. Almost all C compilers have default warnings and errors that do not
match the standards requirements for C. Often they do this in both
directions - failing to issue diagnostics on things that the standards
require, and also issuing errors (halting compilation) for things that
the standard allows. Almost all C compilers allow you to tune warnings
and errors.

4. Some C compilers aim to provide conforming modes, often for several
standard versions, even though they are non-conforming (see 2 and 3
above) by default. Others don't try to conform to any particular C
standard, and can only very loosely be called a C compiler.

5. A "C implementation" needs a compiler, a standard library, headers, a
linker, perhaps an assembler, and a way to run the program on the
target. These might be provided together, or combined from different
places. For example, Microsoft provides everything with their MSVC
tools. For gcc-based toolchains, GCC writes the compiler but does not
provide binaries. The assembler and linker often come from the binutils
project (which again does not provide binaries), but other assemblers
and linkers may be used. Various libraries may be used, depending on
the target, including glibc, newlib, musl, newlib-nano, redlib, avrlib,
and many others. Users can get the parts individually, or more often
they get packaged toolchains from Debian, Redhat, TDM, mingw-64, MS WSL,
NXP, TI, Microchip, or many others according to their needs.

Is any of that new to you? Can you honestly say you have not been told
all this, many, many times?

You /know/ how to make gcc and clang compile standard C. Yet you insist
on faking ignorance. You are either the most thick-witted programmer
around, or you are a dishonest troll who goes out of their way to spread
FUD. And we know you are not thick-witted.

>
>> $ cc --pedantic-errors -o /tmp/a /tmp/t.c
>> /tmp/t.c: In function 'main':
>> /tmp/t.c:4:7: error: ISO C forbids zero-size array 'A' [-Wpedantic]
>>     int A[0];
>>         ^
>> /tmp/t.c:5:11: error: ISO C forbids empty initializer braces [-Wpedantic]
>>     int B[]={};
>>             ^
>> /tmp/t.c:5:7: error: zero or negative size array 'B'
>>     int B[]={};
>>         ^
>> $
>
> So, DOES C HAVE ZERO-LENGTH ARRAYS OR NOT?
>

No.

> It's a really simple question!
>

With a really simple answer, known to anyone who has learned a
reasonable understanding of the C language - and certainly known to
anyone who has read the relevant part of the standard to see the answer
for themselves. (It is in 6.7.6.2p1 - the section with the cryptic and
barely incomprehensible title "Array declarators", in the chapter titled
"Declarations".)

> Because this program easily passes:
>
>   int A[0];
>
> This one doesn't, qne without needing to use -pedantic  or
> -pedantic-errors:
>
>   int A[-1];
>
> If the answer is No, why is gcc so reluctant to complain about it
> compared with the -1 size?
>

Zero-length arrays are a gcc extension. You can read about them here,
under the mysterious and hard-to-find section of the gcc manual titled
"Arrays of Length Zero" :

<https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html>

There are a large number of features of C99 that started off as gcc
extensions in the 90's, before being standardised for C99. Some were
used pretty much directly, others where changed or adapted before
standardisation. Zero-length arrays were not incorporated in C99, but
their main use-case was taken with a slightly modified syntax as
flexible array struct members. gcc has an entirely reasonable policy of
not removing extensions that existing code may rely on, even if there
are newer standard ways to get a similar effect.

On 10/01/2024 07:28, Lawrence D'Oliveiro wrote:
> On Wed, 10 Jan 2024 05:28:43 -0000 (UTC), Kaz Kylheku wrote:
>
>> Please don't get Bart started on makefiles!
>
> Does he prefer Ninja?

He prefers whining about what he has to type by hand. He'd rather spend
thousands of times more time, effort and keypresses complaining to
people here (none of whom are, AFAIK, the author of any "make" tool)
than he would need in order to write a little .bat file on his Windows
system.

It's incredible, really.

On 10/01/2024 08:40, Chris M. Thomasson wrote:
> On 1/9/2024 9:28 PM, Kaz Kylheku wrote:
>> On 2024-01-10, tTh <tth@none.invalid> wrote:
>>> On 1/10/24 01:40, Bart wrote:
>>>> An easy compiler is one where you just do:
>>>>
>>>>      gcc prog
>>>>
>>>> and not, at the very least:
>>>>
>>>>      gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>>
>>>> Meanwhile I routinely test C programs on half a dozen compilers. I
>>>> can't
>>>> be bothered with all this crap.
>>>
>>>      So do as all of us do : put this crap in a Makefile or
>>>      a shell script, and forget about it.
>>
>> Please don't get Bart started on makefiles!
>>
>
> Don't get me started about freaking out for some minutes when I failed
> to use a god damn tab! My makefile would not work. God damn it! Ahhhh,
> that was around 20 years ago.

The author of "make" described the distinction between tabs and spaces
to be his worst mistake ever - but use of the tool took off too quickly
for him to change it.

The difference between Bart and everyone else is that when other people
make a tab mistake, they learn from it - and even 20 years on, you still
remember. Bart seems to forget things seconds after someone tells him
how to use any program that he has not written himself. (It takes him a
little longer to forget how his own programs and languages work.)

On 10/01/2024 03:14, Bart wrote:
> On 10/01/2024 02:00, Scott Lurndal wrote:
>> Bart <bc@freeuk.cm> writes:
>>> On 10/01/2024 00:05, Keith Thompson wrote:
>>>> Bart <bc@freeuk.cm> writes:
>>
>>> An easy compiler is one where you just do:
>>>
>>>     gcc prog
>>>
>>> and not, at the very least:
>>>
>>>     gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>
>>
>> $ functions c
>> function c
>> {
>>    gcc -o "$1" -std=c11 -pedantic-errors "$1".c
>> }
>> $ cat a.c
>> #include <stdio.h>
>>
>> int
>> main(int argc, const char **argv, const char **envp)
>> {
>>
>>      printf("Hello World\n");
>>
>>      return 0;
>> }
>> $ c a
>> $ ./a
>> Hello World
>>
>> Can't get any more concise than that.
>
> Great. Now tell the gcc people that's what it should do ANYWAY.

But it is /not/ what gcc should do.

You seem to be mixing up "what Bart wants" with "what countless other
people want". Write your own tools to revolve around your own selfish
needs if that's your preference, but don't expect everyone else to
change their worlds to suit /you/.

Scott wrote that as an example that might suit you. I am confident that
the compiler options he mostly uses are different from that - and that
he uses a variety of different options and different times, and that
they are different from the options /I/ use or anyone else uses. That's
why anyone who can actually use a compiler picks their options
themselves and uses tools to track them (whether it is a bash function,
a bat file, a makefile, an IDE, or any one of fifty different solutions
that are far better than whining to the wrong people - or even whining
to the right people).

On 09/01/2024 23:12, Kaz Kylheku wrote:
> On 2024-01-09, Bart <bc@freeuk.cm> wrote:

>> Don't tell me: gcc has some option to warn of using octal literals. So
>> your 'successful' language relies on extensive extra tools (all the
>> stuff in that support truck) to keep it useable.
>
> Unfortunately, it is a cynical observation that languages that don't
> require tools tend not to attract people.

A less cynical observation would suggest that a successful language is
one that is used a lot, and therefore attracts additional tools that
make its use better.

On 10/01/2024 08:37, David Brown wrote:
> On 09/01/2024 23:22, Bart wrote:

> 1. C is a language defined by the standards.  Without further
> qualification, "C" refers to the latest published ISO standard -
> currently C17.  But it's also fine to refer to specific standards, such
> as C99.  The standards define the language syntax, constraints, required
> diagnostics (implementations are free to choose warnings or hard
> errors), and standard library specifications.  There are also many
> pre-standard C versions, for which "K&R C" is /almost/ a standard.
>
> 2. Almost all C compilers implement some extensions by default.  These
> extensions are not C, but are compiler-specific language variants.  Some
> people find them useful, other people prefer to stick to standard C.
> Some extensions are so widely implemented that they may be considered a
> pseudo-standard, others are very compiler or target specific.
>
> 3. Almost all C compilers have default warnings and errors that do not
> match the standards requirements for C.  Often they do this in both
> directions - failing to issue diagnostics on things that the standards
> require, and also issuing errors (halting compilation) for things that
> the standard allows.  Almost all C compilers allow you to tune warnings
> and errors.
>
> 4. Some C compilers aim to provide conforming modes, often for several
> standard versions, even though they are non-conforming (see 2 and 3
> above) by default.  Others don't try to conform to any particular C
> standard, and can only very loosely be called a C compiler.
>
> 5. A "C implementation" needs a compiler, a standard library, headers, a
> linker, perhaps an assembler, and a way to run the program on the
> target.  These might be provided together, or combined from different
> places.

My original implementation for Windows used these two files only:

bcc.exe (about 1MB)
msvcrt.dll

bcc.exe includes the compiler, headers and assembler (there was no linker).

My current one splits it up into 4 files:

mcc.exe (264KB)
aa.exe (Assembler, 94KB, still no linker)
msvcrt.dll
windows.h (optional)

A linker is only needed to statically combine my code with that from
other compilers.

>  For example, Microsoft provides everything with their MSVC
> tools.  For gcc-based toolchains, GCC writes the compiler but does not
> provide binaries.  The assembler and linker often come from the binutils
> project (which again does not provide binaries), but other assemblers
> and linkers may be used.  Various libraries may be used, depending on
> the target, including glibc, newlib, musl, newlib-nano, redlib, avrlib,
> and many others.  Users can get the parts individually, or more often
> they get packaged toolchains from Debian, Redhat, TDM, mingw-64, MS WSL,
> NXP, TI, Microchip, or many others according to their needs.

Other smaller C Windows compilers (lccwin, pellesc, dmc are older ones,
then there is tcc) are self-contained without any of that complexity, or
the need to divy up the implementation into assorted parts that all live
in different places or that have to be individually sourced.

>
> You /know/ how to make gcc and clang compile standard C.  Yet you insist
> on faking ignorance.  You are either the most thick-witted programmer
> around, or you are a dishonest troll who goes out of their way to spread
> FUD.  And we know you are not thick-witted.

Suppose you were given a C program to build. There are no instructions
(or there are instructions, but they are encoded inside some script in a
proprietory language that you don't understand and don't have a tool for).

How do you know what to tell gcc to compile it?

Suppose you took a program that you know perfectly well how to compile
with gcc, but you some reason you don't have it (maybe all instances of
gcc vanished overnight after some power blockout).

You have one or two lesser compilers with not many options; what do you
tell those how to compile that program?

(I'll make it easy and suggest neither program depends on gnu extensions.)

Both examples are basically my situation. I'm either building other
people' software, using a range of compilers (so if it works with A and
B with no special options, I'm not interested in pandering to gcc with a
huge laundry list of instructions)...

.... or I'm generating C code of my own, which used to be compilable with
half a dozen C compilers with NO SPECIAL OPTIONS, but now I support 3,
and one or two of them might need a special option.

So, in my world, I really don't want to know about all that gcc palaver.

(You go to rent a car. In most cases all you need is a key to open the
door and turn on the ignition. Except the car made by gcc, which needs a
dozen different keys, and a long list of configuration options to be set
first: wheels:4; LHD or RHD: RHD, etc.

You see my frustration? Using the C language should be driving a car.)

You already know I have no idea about what version of C is involved,
only that it needs to pass with the compilers I list using the options
(or lack of options) that I stipulate at the top of the source file.

But you will be able to infer that I don't depend in gnu C extensions.

> Zero-length arrays are a gcc extension.

I wonder how many thousands of lines of code it took to implement such
an extension?

On 10/01/2024 13:12, bart wrote:
> On 10/01/2024 08:37, David Brown wrote:
>> On 09/01/2024 23:22, Bart wrote:
>
>> 1. C is a language defined by the standards.  Without further
>> qualification, "C" refers to the latest published ISO standard -
>> currently C17.  But it's also fine to refer to specific standards,
>> such as C99.  The standards define the language syntax, constraints,
>> required diagnostics (implementations are free to choose warnings or
>> hard errors), and standard library specifications.  There are also
>> many pre-standard C versions, for which "K&R C" is /almost/ a standard.
>>
>> 2. Almost all C compilers implement some extensions by default.  These
>> extensions are not C, but are compiler-specific language variants.
>> Some people find them useful, other people prefer to stick to standard
>> C. Some extensions are so widely implemented that they may be
>> considered a pseudo-standard, others are very compiler or target
>> specific.
>>
>> 3. Almost all C compilers have default warnings and errors that do not
>> match the standards requirements for C.  Often they do this in both
>> directions - failing to issue diagnostics on things that the standards
>> require, and also issuing errors (halting compilation) for things that
>> the standard allows.  Almost all C compilers allow you to tune
>> warnings and errors.
>>
>> 4. Some C compilers aim to provide conforming modes, often for several
>> standard versions, even though they are non-conforming (see 2 and 3
>> above) by default.  Others don't try to conform to any particular C
>> standard, and can only very loosely be called a C compiler.
>>
>> 5. A "C implementation" needs a compiler, a standard library, headers,
>> a linker, perhaps an assembler, and a way to run the program on the
>> target.  These might be provided together, or combined from different
>> places.
>
> My original implementation for Windows used these two files only:
>

No one cares. It does not matter how any particular C implementation
does it, it only matters that there are many ways to package them. I
gave examples purely as examples. The question is, do you understand
what I wrote above, and is anything there new or surprising to you?

>
>>   For example, Microsoft provides everything with their MSVC tools.
>> For gcc-based toolchains, GCC writes the compiler but does not provide
>> binaries.  The assembler and linker often come from the binutils
>> project (which again does not provide binaries), but other assemblers
>> and linkers may be used.  Various libraries may be used, depending on
>> the target, including glibc, newlib, musl, newlib-nano, redlib,
>> avrlib, and many others.  Users can get the parts individually, or
>> more often they get packaged toolchains from Debian, Redhat, TDM,
>> mingw-64, MS WSL, NXP, TI, Microchip, or many others according to
>> their needs.
>

No one cares.

>
>>
>> You /know/ how to make gcc and clang compile standard C.  Yet you
>> insist on faking ignorance.  You are either the most thick-witted
>> programmer around, or you are a dishonest troll who goes out of their
>> way to spread FUD.  And we know you are not thick-witted.
>
> Suppose you were given a C program to build. There are no instructions
> (or there are instructions, but they are encoded inside some script in a
> proprietory language that you don't understand and don't have a tool for).
>
> How do you know what to tell gcc to compile it?

I might make some guesses, because I know the typical flags needed for
gcc (as do you, as you have been told them countless times). If these
don't work and there are no clear instructions, I might ask the program
developers for more information. I might google for it, or ask
generally in appropriate forums (which comp.lang.c is not).

Without the slightest doubt, I can say that if it were possible to build
it using /your/ C compiler, and does not use extensions unsupported by
gcc, then I could get it to build with gcc without much trouble. I
think the same would apply to pretty much anyone who has some experience
using gcc from the command line.

>
> Suppose you took a program that you know perfectly well how to compile
> with gcc, but you some reason you don't have it (maybe all instances of
> gcc vanished overnight after some power blockout).

Now you sound as silly as that C90 fanatic who turns up here occasionally.

<snip>

>> Zero-length arrays are a gcc extension.
>
> I wonder how many thousands of lines of code it took to implement such
> an extension?
>

I have no idea. It was a good idea at the time, because C90 did not
have flexible array members. It is now pretty much unnecessary, though
I am sure some people use "[0]" instead of "[]" in their flexible array
struct members. And some might take advantage of gcc's slightly greater
flexibility here than the C standards define.

On 10/01/2024 13:17, David Brown wrote:
> On 10/01/2024 13:12, bart wrote:

>>>   For example, Microsoft provides everything with their MSVC tools.
>>> For gcc-based toolchains, GCC writes the compiler but does not
>>> provide binaries.  The assembler and linker often come from the
>>> binutils project (which again does not provide binaries), but other
>>> assemblers and linkers may be used.  Various libraries may be used,
>>> depending on the target, including glibc, newlib, musl, newlib-nano,
>>> redlib, avrlib, and many others.  Users can get the parts
>>> individually, or more often they get packaged toolchains from Debian,
>>> Redhat, TDM, mingw-64, MS WSL, NXP, TI, Microchip, or many others
>>> according to their needs.
>>
>
> No one cares.

But you cared enough to list all those complicated ways that some have
implemented C. It sounded almost lovingly.

It's as though you're looking down disdainfully at all those seeking to
produce smaller simpler products: Here, THIS is how you produce a C
compiler! It has to be Big! And Slow! It has to be Complicated! It has
to have lots of Buttons!

You know, the most remarkable and impressive product for me is the Tiny
C compiler. It's Small. It's Fast. It's Simple.

For my generated C code, only 3 files of Tiny C, totalling 230KB, are
needed to turn it near-instantly into executable code. As a compiler
backend target, it's a solution that is 100 times smaller and 100 times
faster than LLVM.

Some people have different opinions about this stuff. C isn't your own
proprietory language that should only be processed with your stipulated
tool sets.

Anybody can implement their own ideas of how it should work. There are
reasons why those people put considerable efforts into those smaller,
self-contained and more user-friendly products.

Oh, I forgot, you don't care.

OK. Well I don't really care about what you're into either! I certainly
don't want to fuck about with -Wextra -Wpedantic -Wall -std=this -ofile
and all that nonsense, when a 10 seconds earlier I'd simpler done 'tcc
prog.c'.

For me a compiler should be as utilitarian and simple to use as a light
switch.

> Without the slightest doubt, I can say that if it were possible to build
> it using /your/ C compiler, and does not use extensions unsupported by
> gcc, then I could get it to build with gcc without much trouble.

You seem to be acknowledging the benefits of passing a code base through
a lesser compiler.

  I
> think the same would apply to pretty much anyone who has some experience
> using gcc from the command line.
>
>>
>> Suppose you took a program that you know perfectly well how to compile
>> with gcc, but you some reason you don't have it (maybe all instances
>> of gcc vanished overnight after some power blockout).
>
> Now you sound as silly as that C90 fanatic who turns up here occasionally.

There are any number of actual scenarios where that can happen. That is,
you don't have access to your favourite compiler.

I actually can supply a C program, and the C compiler needed to build it
into an executable, on a floppy disk, in most cases. It can be as little
as 3 files (source, compiler, assembler); it will be instantly obvious
if there's one missing, and what the implications would be.

What is the minimum number of actual (ie. not ZIP) files needed to
bundle gcc in the same way? Give me a number. (I guess you don't know; I
thought you knew your tools inside out!)

>> I wonder how many thousands of lines of code it took to implement such
>> an extension?
>>
>
> I have no idea.  It was a good idea at the time, because C90 did not
> have flexible array members.  It is now pretty much unnecessary, though
> I am sure some people use "[0]" instead of "[]" in their flexible array
> struct members.  And some might take advantage of gcc's slightly greater
> flexibility here than the C standards define.

I was thinking more of this:

void* table[] = {
// &a,
// &b,
// &c,
};

Temporarily comment out those entries (maybe they don't exist yet, or to
test how well program logic copes with an empty list).

David Brown <david.brown@hesbynett.no> writes:
>On 10/01/2024 03:14, Bart wrote:
>> On 10/01/2024 02:00, Scott Lurndal wrote:
>>> Bart <bc@freeuk.cm> writes:
>>>> On 10/01/2024 00:05, Keith Thompson wrote:
>>>>> Bart <bc@freeuk.cm> writes:
>>>
>>>> An easy compiler is one where you just do:
>>>>
>>>>     gcc prog
>>>>
>>>> and not, at the very least:
>>>>
>>>>     gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>
>>>
>>> $ functions c
>>> function c
>>> {
>>>    gcc -o "$1" -std=c11 -pedantic-errors "$1".c
>>> }
>>> $ cat a.c
>>> #include <stdio.h>
>>>
>>> int
>>> main(int argc, const char **argv, const char **envp)
>>> {
>>>
>>>      printf("Hello World\n");
>>>
>>>      return 0;
>>> }
>>> $ c a
>>> $ ./a
>>> Hello World
>>>
>>> Can't get any more concise than that.
>>
>> Great. Now tell the gcc people that's what it should do ANYWAY.
>
>But it is /not/ what gcc should do.
>
>You seem to be mixing up "what Bart wants" with "what countless other
>people want". Write your own tools to revolve around your own selfish
>needs if that's your preference, but don't expect everyone else to
>change their worlds to suit /you/.
>
>
>Scott wrote that as an example that might suit you.

> I am confident that
>the compiler options he mostly uses are different from that - and that
>he uses a variety of different options and different times, and that
>they are different from the options /I/ use or anyone else uses.

Indeed. I use a Makefile and the Makefile.defs include alone has 373
lines - something sure to piss Bart off. Of course, the project
has:

SLOC Directory SLOC-by-Language (Sorted)
7316068 include ansic=7274603,cpp=41465
899374 tests python=763294,ansic=82789,asm=34873,cpp=18013,sh=405
885492 io cpp=603113,ansic=281285,python=466,sh=324,asm=304
133342 processor cpp=131855,python=1487
133153 3rd_party cpp=133033,sh=78,python=42
26803 tools python=17834,cpp=4300,sh=1903,ansic=1459,perl=1199,
ruby=108
16754 gen ansic=16754
10955 platform cpp=10955
8392 common cpp=8392
5290 bin cpp=5118,python=172
2204 cpc cpp=2204
1883 top_dir cpp=1883
1430 noc cpp=1430
560 shim cpp=560

SLOC doesn't include whitespace or comments.

That's about 10 million lines of code across several hundred source
and include files.

Yet, the entire application can be built with

$ make

bart <bc@freeuk.com> writes:

>My original implementation for Windows used these two files only:
>
> bcc.exe (about 1MB)

Why do you think anyone here cares?

On 10/01/2024 15:31, bart wrote:
> On 10/01/2024 13:17, David Brown wrote:
>> On 10/01/2024 13:12, bart wrote:
>
>
>>>>   For example, Microsoft provides everything with their MSVC tools.
>>>> For gcc-based toolchains, GCC writes the compiler but does not
>>>> provide binaries.  The assembler and linker often come from the
>>>> binutils project (which again does not provide binaries), but other
>>>> assemblers and linkers may be used.  Various libraries may be used,
>>>> depending on the target, including glibc, newlib, musl, newlib-nano,
>>>> redlib, avrlib, and many others.  Users can get the parts
>>>> individually, or more often they get packaged toolchains from
>>>> Debian, Redhat, TDM, mingw-64, MS WSL, NXP, TI, Microchip, or many
>>>> others according to their needs.
>>>
>>
>> No one cares.
>
> But you cared enough to list all those complicated ways that some have
> implemented C. It sounded almost lovingly.

I made no comment on what I liked or did not like about it - it was a
factual list. I made it for /your/ benefit.

I don't care about how different C toolchains are made, or by whom, or
whether they are big or small. I care that the ones /I/ need are
obtainable in a suitable manner for /my/ needs, running on /my/ choice
of OS, and for /my/ choice of target. They must be available at an
appropriate cost, and it must be possible to archive them indefinitely
and use them without any awkward "license protect" systems. But it does
not bother me if the package is 1 MB or 1 GB, 1 program or 1000 programs
- those are not relevant concerns for professional programmers.

I do, however, try my best to help people in groups like this. That
includes writing posts to try to help and educate /you/. It gets
increasingly frustrating, however.

> You know, the most remarkable and impressive product for me is the Tiny
> C compiler. It's Small. It's Fast. It's Simple.

It is almost entirely useless, except for the very, very few people who
/need/ a C compiler that is very small. In the days of 3.5" floppy
disks for rescue disks, it was useful. In the days of 16 GB USB flash
devices costing pennies, it is irrelevant.

It is still remarkable, and still impressive - I have no disagreements
there. It will always be an impressive achievement - that will not
change with time. It might also be fun to play with. But it is still
basically useless. It is no longer a particularly useful or needed
tool. Lots of C compilers were once relevant, and now are not, except
perhaps for a few very niche uses.

> Anybody can implement their own ideas of how it should work. There are
> reasons why those people put considerable efforts into those smaller,
> self-contained and more user-friendly products.

"User-friendly" /is/ something worth caring about. So is ease of
installation. Small size, self-contained binaries - those are not of
concern to users. It is absolutely a good thing for many people that a
tool is easy to understand and use - but no one cares what goes on
behind the scenes to make it work, as long as it works fast enough to be
practical on sensible computers. (A half-arsed compiler that implements
some unknown and undocumented subset of C, with random changes at the
whim of the developer, cannot ever be "user-friendly" for anyone other
than said developer.)

To some extent, "user-friendly" will be at odds with flexibility and
features, so there is a balance to be found.

>
> For me a compiler should be as utilitarian and simple to use as a light
> switch.

For me, a compiler should be something found in the real world and not a
deluded fantasy.

>
>> Without the slightest doubt, I can say that if it were possible to
>> build it using /your/ C compiler, and does not use extensions
>> unsupported by gcc, then I could get it to build with gcc without much
>> trouble.
>
> You seem to be acknowledging the benefits of passing a code base through
> a lesser compiler.
>

You seem to be inventing things that I never wrote or implied.

Bart <bc@freeuk.cm> writes:
> On 10/01/2024 00:49, Keith Thompson wrote:
....
> I spent some minutes trying to find where this zero-length array
> business originated. It was from you:

No, it originated from the C standard: "... the [ and ] may delimit an
expression ... If the expression is a constant expression, it shall have
a value greater than zero." (6.7.6.2p1).

>>No, it doesn't. C doesn't have zero-length arrays.
>
> You say "C", but don't say which version or which common
> dialect.

This group is not specific to any particular compiler. Therefore, unless
otherwise specified, when I refer to C, I an usually referring to
standard C unless otherwise specified, and more particularly, to the
latest approved version of C, unless otherwise specified. Many other
people follow similar policies. There's very little (if anything) that
can usefully be said about all variants of C - the only meaningful
things you can say are about particular variants.

> ... Apperently the most commonly used dialect is gnu C,

The Gnu C compiler is one of the most widely used, but a lot of people
use it to compile standard C rather than Gnu C - unlike you, most
programmers don't find it particularly difficult to figure out how to
arrange that. I have no idea whether it's more or less popular than
standard C.

> I'm still none the wiser. Can I actually use zero-length arrays? Yes,
> No, Maybe, Only with this or that compiler or that bunch of options.

You can only use zero-length arrays with particular compilers. The ones
that do allow it, generally use options to disable that feature, not to
enable it.

You have two main options:
1. Write separate versions of your code for each compiler you target,
possibly controlled by conditional compilation or makefiles.
2. Choose a particular version of the C standard, and write code that
works with that version. Then, for each target compiler, figure out how
to put it into a mode where it will compile according to that version.
The standard leaves many things unspecified, but it's quite feasible to
write code that has the desired behavior regardless of which choice the
compiler makes for any unspecified behavior.

On 1/10/24 15:31, bart wrote:

> What is the minimum number of actual (ie. not ZIP) files needed to
> bundle gcc in the same way? Give me a number. (I guess you don't know; I
> thought you knew your tools inside out!)

$ sudo apt install gcc

--
+---------------------------------------------------------------------+
| https://tube.interhacker.space/a/tth/video-channels |
+---------------------------------------------------------------------+

On 10/01/2024 14:51, Scott Lurndal wrote:
> bart <bc@freeuk.com> writes:
>
>> My original implementation for Windows used these two files only:
>>
>> bcc.exe (about 1MB)
>
>
> Why do you think anyone here cares?

Why do you think anyone cares about your makefiles?

It's a counter-example to somebody who might think implementations
really need to be as elaborate as DB was suggesting.

On 10/01/2024 14:49, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 10/01/2024 03:14, Bart wrote:
>>> On 10/01/2024 02:00, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.cm> writes:
>>>>> On 10/01/2024 00:05, Keith Thompson wrote:
>>>>>> Bart <bc@freeuk.cm> writes:
>>>>
>>>>> An easy compiler is one where you just do:
>>>>>
>>>>>     gcc prog
>>>>>
>>>>> and not, at the very least:
>>>>>
>>>>>     gcc prog.c -prog.exe -std=c11 -pedantic-errors
>>>>
>>>>
>>>> $ functions c
>>>> function c
>>>> {
>>>>    gcc -o "$1" -std=c11 -pedantic-errors "$1".c
>>>> }
>>>> $ cat a.c
>>>> #include <stdio.h>
>>>>
>>>> int
>>>> main(int argc, const char **argv, const char **envp)
>>>> {
>>>>
>>>>      printf("Hello World\n");
>>>>
>>>>      return 0;
>>>> }
>>>> $ c a
>>>> $ ./a
>>>> Hello World
>>>>
>>>> Can't get any more concise than that.
>>>
>>> Great. Now tell the gcc people that's what it should do ANYWAY.
>>
>> But it is /not/ what gcc should do.
>>
>> You seem to be mixing up "what Bart wants" with "what countless other
>> people want". Write your own tools to revolve around your own selfish
>> needs if that's your preference, but don't expect everyone else to
>> change their worlds to suit /you/.
>>
>>
>> Scott wrote that as an example that might suit you.
>
>> I am confident that
>> the compiler options he mostly uses are different from that - and that
>> he uses a variety of different options and different times, and that
>> they are different from the options /I/ use or anyone else uses.
>
> Indeed. I use a Makefile and the Makefile.defs include alone has 373
> lines - something sure to piss Bart off. Of course, the project
> has:
>
> SLOC Directory SLOC-by-Language (Sorted)
> 7316068 include ansic=7274603,cpp=41465
> 899374 tests python=763294,ansic=82789,asm=34873,cpp=18013,sh=405
> 885492 io cpp=603113,ansic=281285,python=466,sh=324,asm=304
> 133342 processor cpp=131855,python=1487
> 133153 3rd_party cpp=133033,sh=78,python=42
> 26803 tools python=17834,cpp=4300,sh=1903,ansic=1459,perl=1199,
> ruby=108
> 16754 gen ansic=16754
> 10955 platform cpp=10955
> 8392 common cpp=8392
> 5290 bin cpp=5118,python=172
> 2204 cpc cpp=2204
> 1883 top_dir cpp=1883
> 1430 noc cpp=1430
> 560 shim cpp=560
>
> SLOC doesn't include whitespace or comments.
>
> That's about 10 million lines of code across several hundred source
> and include files.
>
> Yet, the entire application can be built with
>
> $ make

I bet you can't. There's something missing. Unless the implicit file
that make uses happens to be in that '$' directory. Usually you have to
navigate to the project first.

So of the two parts a typical build needs: the program, script or
process that is launched to do the work, and the input needed, one has
already been provided.

A more sensible way would be to require:

make inputfile

Then you could build stuff from anywhere.

BTW well done for discovering that, if a build sequence requires
multiple commands to be executed, you can put those into a 'script' that
requires a single invocation.

Just as long as you realise that this isn't doing away with those
multiple steps, it's hiding them away not simplifying, and adding ONE
MORE step to the process.

The stuff I do is genuine simplification.

bart <bc@freeuk.com> writes:
> On 10/01/2024 14:49, Scott Lurndal wrote:
[...]
>> Yet, the entire application can be built with
>> $ make
>
> I bet you can't. There's something missing. Unless the implicit file
> that make uses happens to be in that '$' directory. Usually you have
> to navigate to the project first.

That '$' is a shell prompt, not a directory.

Yes, you have to "cd" (like "chdir" on Windows) to the project directory
before typing "make". You also have to make sure the computer is
powered on, login, launch a shell, and maybe one or two other things
before you get to that point.

> So of the two parts a typical build needs: the program, script or
> process that is launched to do the work, and the input needed, one has
> already been provided.
>
> A more sensible way would be to require:
>
> make inputfile
>
> Then you could build stuff from anywhere.

Of course "make" fully supports that, though not with your suggested
syntax.

"make -C dir" tells "make" to change to the specified directory before
doing anything else. "make -f filename" tells it to use the specified
file rather than the default "Makefile". "make filename" tells "make"
to *build* "filename", not to read it.

With no arguments, it starts in the current directory, reads rules from
"Makefile", and builds the first target listed in that file.

I've glossed over a minor point about the default makefile name, but
I've already told you more than you'll be willing to learn.

[...]

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

On 10/01/2024 15:51, David Brown wrote:
> On 10/01/2024 15:31, bart wrote:

> It is almost entirely useless, except for the very, very few people who
> /need/ a C compiler that is very small.  In the days of 3.5" floppy
> disks for rescue disks, it was useful.  In the days of 16 GB USB flash
> devices costing pennies, it is irrelevant.

16 GB can hold a great deal of useful DATA: images, audio and video for
example. It also tends to be consumed sequentially.

But it is a mistake to think it makes it OK have programs, ie. CODE,
that are 0.1GB, 1GB or 10GB in size. Code complexity doesn't scale
linearly as data does.

It means complicated, slow, cumbersome programs, that require extra
power and memory resources. And buggy ones.

> It is still remarkable, and still impressive - I have no disagreements
> there.  It will always be an impressive achievement - that will not
> change with time.  It might also be fun to play with.  But it is still
> basically useless.  It is no longer a particularly useful or needed
> tool.  Lots of C compilers were once relevant, and now are not, except
> perhaps for a few very niche uses.
>
>
>> Anybody can implement their own ideas of how it should work. There are
>> reasons why those people put considerable efforts into those smaller,
>> self-contained and more user-friendly products.
>
> "User-friendly" /is/ something worth caring about.  So is ease of
> installation.  Small size, self-contained binaries - those are not of
> concern to users.

It means I can email you both a source file, and the compiler or
interpreter needed to build or run it (setting aside AV issues). Imagine
supplying gcc or CPython as an email attachment!

Somebody else may be implementing a language with C backend. Rather than
requiring their users to install a C system which will dwarf there own
product, or that is so slow that it would be like hitting a break wall
as soon as they invoke it, a small, fast C compiler could be just
bundled and invoked transparently as there is no disproportionate latency.

> It is absolutely a good thing for many people that a
> tool is easy to understand and use - but no one cares what goes on
> behind the scenes to make it work, as long as it works fast enough to be
> practical on sensible computers.  (A half-arsed compiler that implements
> some unknown and undocumented subset of C, with random changes at the
> whim of the developer, cannot ever be "user-friendly" for anyone other
> than said developer.)

This is what I mean by user-friendly:

c:\c>gcc hello
C:\tdm\bin\ld.exe: cannot find hello: No such file or directory
collect2.exe: error: ld returned 1 exit status

c:\c>gcc hello.c

c:\c>hello
'hello' is not recognized as an internal or external command,
operable program or batch file.

c:\c>gcc hello.c -hello
gcc: error: unrecognized command-line option '-h'

c:\c>gcc hello.c -ohello

c:\c>hello
Hello, World! 00007ff6923d13b4

The above tries to compile hello.c with gcc. The first attempt doesn't
work. The second does, as no error is displayed. But what exactly has it
compiled it to? As there is no file called 'hello.exe.

It needs '-o'. The third attempt has a typo, the fourth finally works.

The user friendly version is this:

c:\c>mcc hello # same input as given to gcc
Compiling hello.c to hello.exe

c:\c>hello
Hello, World! 0000000000401000

The compiler doesn't need the extension. It tells you exactly what it is
doing, incuding where it will write the output.

Please don't talk to me about user-friendly, you don't seem to have a clue.

bart <bc@freeuk.com> writes:
>On 10/01/2024 14:51, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> My original implementation for Windows used these two files only:
>>>
>>> bcc.exe (about 1MB)
>>
>>
>> Why do you think anyone here cares?
>
>Why do you think anyone cares about your makefiles?

What makes you think I care if anyone cares about my makefiles?

On 2024-01-10, David Brown <david.brown@hesbynett.no> wrote:
> On 09/01/2024 23:12, Kaz Kylheku wrote:
>> On 2024-01-09, Bart <bc@freeuk.cm> wrote:
>
>
>>> Don't tell me: gcc has some option to warn of using octal literals. So
>>> your 'successful' language relies on extensive extra tools (all the
>>> stuff in that support truck) to keep it useable.
>>
>> Unfortunately, it is a cynical observation that languages that don't
>> require tools tend not to attract people.
>
> A less cynical observation would suggest that a successful language is
> one that is used a lot, and therefore attracts additional tools that
> make its use better.

Also, there is no language for which the implementations have the final
word on any program, such that the users cannot imagine needing new
kinds of diagnostics.

What is a diagnostic? It's something which evaluate a
truth-valued proposition about a program, and reports if it
is true.

A program has a large number of properties about which true propositions
can be stated. Any of those truths could potentially be a useful
diagnostic to someone.

It is not realistic to expect that a language specification can state
all the propositions that may be diagnosed, such that no others may be
diagnosed.

Furthermore, users may want to be informed about certain programs which
are correct by the language, but which have some undesirable property,
specific to their requirements, such as a local coding standard or
even application-specific requirements.

E.g. a C program which puts sensitive info into an improperly procured
temporary file might be correct by ISO C, but we can imagine a
sophisticated diagnostic identifying the situation.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 10/01/2024 18:39, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
>> On 10/01/2024 14:49, Scott Lurndal wrote:
> [...]
>>> Yet, the entire application can be built with
>>> $ make
>>
>> I bet you can't. There's something missing. Unless the implicit file
>> that make uses happens to be in that '$' directory. Usually you have
>> to navigate to the project first.
>
> That '$' is a shell prompt, not a directory.
>
> Yes, you have to "cd" (like "chdir" on Windows) to the project directory
> before typing "make". You also have to make sure the computer is
> powered on, login, launch a shell, and maybe one or two other things
> before you get to that point.

You're missing the point. SL is making a big deal about the fact that
you can type 'make' without providing any apparent input. But that input
is provided when you use 'cd' to get the relevant folder.

Or do you think that the 'make' command provided will build that
specific project irrespective of the CWD?

On 10/01/2024 18:58, bart wrote:
> On 10/01/2024 14:51, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> My original implementation for Windows used these two files only:
>>>
>>>     bcc.exe           (about 1MB)
>>
>>
>> Why do you think anyone here cares?
>
> Why do you think anyone cares about your makefiles?
>

Scott was trying to help you (and if you had done him the courtesy of
reading his post, you'd see it was not using make).

> It's a counter-example to somebody who might think implementations
> really need to be as elaborate as DB was suggesting.
>

Again, you are making stuff up. I never suggested C implementations
need to be elaborate. I said they could be elaborate, or not, but that
no one really cares about sizes or numbers of files. (I agree that some
people care about being complicated to use. gcc is only complicated if
you choose to use a lot of options - very few are needed, and most
people capable of programming in C can google for their gcc option needs
in a few minutes at most.)

bart <bc@freeuk.com> writes:
> On 10/01/2024 18:39, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>> [...]
>>>> Yet, the entire application can be built with
>>>> $ make
>>>
>>> I bet you can't. There's something missing. Unless the implicit file
>>> that make uses happens to be in that '$' directory. Usually you have
>>> to navigate to the project first.
>> That '$' is a shell prompt, not a directory.
>> Yes, you have to "cd" (like "chdir" on Windows) to the project
>> directory
>> before typing "make". You also have to make sure the computer is
>> powered on, login, launch a shell, and maybe one or two other things
>> before you get to that point.
>
> You're missing the point.

No.

> SL is making a big deal about the fact that
> you can type 'make' without providing any apparent input.

Meh. The "make" command has sensible defaults -- at least a lot of us
find them sensible. You complain about having to provide options. He
showed you a case where you don't, once things are set up.

> But that
> input is provided when you use 'cd' to get the relevant folder.

Of course. I'm certain that Scott is aware of that and wasn't trying to
hide anything.

> Or do you think that the 'make' command provided will build that
> specific project irrespective of the CWD?

Of course not.

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

On 10/01/2024 20:24, bart wrote:
> On 10/01/2024 18:39, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>>> On 10/01/2024 14:49, Scott Lurndal wrote:
>> [...]
>>>> Yet, the entire application can be built with
>>>> $ make
>>>
>>> I bet you can't. There's something missing. Unless the implicit file
>>> that make uses happens to be in that '$' directory. Usually you have
>>> to navigate to the project first.
>>
>> That '$' is a shell prompt, not a directory.
>>
>> Yes, you have to "cd" (like "chdir" on Windows) to the project directory
>> before typing "make".  You also have to make sure the computer is
>> powered on, login, launch a shell, and maybe one or two other things
>> before you get to that point.
>
> You're missing the point. SL is making a big deal about the fact that
> you can type 'make' without providing any apparent input. But that input
> is provided when you use 'cd' to get the relevant folder.
>
> Or do you think that the 'make' command provided will build that
> specific project irrespective of the CWD?

The input is the makefile, and all the source files. Did you think
Scott was claiming that just typing "make" somewhere on any Linux
machine would build his vast project, without having the makefile(s) or
source files available or being in the right directory?

And are you still so ignorant about "make" that you think it is
equivalent to a script?

On 10/01/2024 20:23, Kaz Kylheku wrote:
> On 2024-01-10, David Brown <david.brown@hesbynett.no> wrote:
>> On 09/01/2024 23:12, Kaz Kylheku wrote:
>>> On 2024-01-09, Bart <bc@freeuk.cm> wrote:
>>
>>
>>>> Don't tell me: gcc has some option to warn of using octal literals. So
>>>> your 'successful' language relies on extensive extra tools (all the
>>>> stuff in that support truck) to keep it useable.
>>>
>>> Unfortunately, it is a cynical observation that languages that don't
>>> require tools tend not to attract people.
>>
>> A less cynical observation would suggest that a successful language is
>> one that is used a lot, and therefore attracts additional tools that
>> make its use better.
>
> Also, there is no language for which the implementations have the final
> word on any program, such that the users cannot imagine needing new
> kinds of diagnostics.
>
> What is a diagnostic? It's something which evaluate a
> truth-valued proposition about a program, and reports if it
> is true.
>
> A program has a large number of properties about which true propositions
> can be stated. Any of those truths could potentially be a useful
> diagnostic to someone.
>
> It is not realistic to expect that a language specification can state
> all the propositions that may be diagnosed, such that no others may be
> diagnosed.
>
> Furthermore, users may want to be informed about certain programs which
> are correct by the language, but which have some undesirable property,
> specific to their requirements, such as a local coding standard or
> even application-specific requirements.
>
> E.g. a C program which puts sensitive info into an improperly procured
> temporary file might be correct by ISO C, but we can imagine a
> sophisticated diagnostic identifying the situation.
>

Agreed (on all points).

People have wildly different requirements. The gcc flags I want for my
builds would be entirely unsuitable for the builds you do, and vice
versa. Bart's idea that we can all use a single simple command is
because he lives in a tiny little bubble with himself at the centre, and
other people's needs or wants are so irrelevant to him that he doesn't
even see that they exist. As far as Bart's concerned, it's easier to
change his language and compiler than to use a flag when invoking a tool.