On 08/08/2023 13:36, Bart wrote:
> On 08/08/2023 12:11, David Brown wrote:
> > On 04/08/2023 20:25, Bart wrote:
> >> Besides, with pretty much every other language with a command-line
> >> build process, if you submit a single source file 'fred.lang', it will
> >> produce a matching executable 'fred.exe` without needing to be told
> how.
> >
> > Pretty much every other language is not C, and does not have the history
> > of C or the history of C compilers.
>
> That is irrelevant. C compilers like Pelles C, lccwin32, DMC, Tiny C
> (Windows), MSVC plus mine of course manage to do it properly, despite
> that history.
>

Equally, you could argue that all these tools do it wrong - because they
don't do it the way users of certain other compilers expect.

As I have said repeatedly, I don't disagree that it could be convenient
to have an executable name generated automatically from the name of the
first C file on the list. I just disagree with the idea that such
behaviour is somehow the only correct or rational choice, or that tools
that do something different from what /you/ personally prefer are "wrong".

One difference that may be significant is that most of the tools you
mention are compilers. The program "gcc" is a driver program - a
front-end - for a range of tools including compilers for different
languages and third-party tools such as assemblers and linkers.

I would expect that only a small proportion of invocations of "gcc" are
actually producing an executable - more will be generating object files,
and some are for other uses (generating assembly or listing files,
dependency files, or other odd use-cases). If I were changing the
default, I would have "gcc prog.c" default to compiling "prog.o", rather
than an executable of any name.

> It is one stupid decision in one compiler that nobody has bothered to
> fix. At least give it an option to override, but in a form where you
> don't need to provide a file name. Example:
>
>     gcc -new prog.c
>
> will use the rule that the name of the executable is taken from the
> first or only submitted C file. Would that have been too hard?
>

I would imagine it would not be particularly hard. But would it be
particularly useful or popular? I doubt it. After all, it is not
easier to use than "gcc -o prog prog.c" would be.

> No. It is just plain stubbornness, because we WANT to still be doing
> -ofile.exe and -lm even into the next millenium.
>

The gcc developers are quite good at implementing features or changes
that make the tool better or easier to use - many of them are paid to do
exactly that. But they do not change defaults just because someone says
they think it is "obviously" better to do things differently - they need
good reason, especially if there is simple to use the tool as it is, and
some existing build scripts might rely on the existing behaviour. It is
not stubbornness that guides them - it is professionalism in maintaining
a project with a vast number of users with many different needs and
preferences.

>
> > And for pretty much every compiled language, you can type "make fred"
> > and get the executable "fred" from the source C, C++, Fortran, D, or
> > whatever.
> >
> > And pretty much every serious programmer uses build tools, regardless of
> > the language - whether it be make, ant, bake, their own batch files,
> > IDEs, or whatever suits them.  I no of no one else who goes so far out
> > of their way to make life difficult for themselves just so that they can
> > complain about how hard it all is.
>
> No so much hard; it just doesn't work. I've seen too many failures of
> 'make' on Windows; I /have/ given it a chance.
>

You have worked long and hard to make things fail, and to find new ways
to get things wrong. I've used "make" on Windows (and DOS before it)
for 30 years or more, and have not seen anything like the trouble you
seem to have. (I don't think "make" is perfect - there's plenty that
can get very messy when you have complex setups, and everyone, including
the original author of make, agrees that the distinction between tabs
and spaces was a really bad design decision.)

But if you don't like make, try one of the dozens of alternatives. Or
write a batch file. Or make your own build program - it's not hard, at
least for a simple arrangement.

> People over-complicate build systems for little reason.

You are always blaming other people. If you want a simple makefile,
write a simple makefile. If you want a simple build system, write a ten
line batch file.

> And ones that
> originate on Linux travel poorly.
>

I am sure that is correct - you wouldn't have said so without solid
evidence. And I am sure you are aware that "make" did not originate on
Linux, and that "make" is not the only build tool around.

> Don't forget that build systems are usually intended for developers,
> where incremental compilation, or organising files into dozens of nested
> files might be important for them.

Don't forget that compilers are also usually intended for developers.

>
> But all that is utterly irrelevant for anyone just wanting to build a
> finished, working program from source.
>

Yes, that's why people use build tools.

Pretty much all software provided as source code will be build using
build tools. The user will type "install.sh", or "setup.py", or
"cmake", or "./configure && make && make install", or whatever the
instructions are for the software. What they will almost /never/ do is
typing in a series of compiler commands and flags.

> That is why when I used to provide distributions as source code, there
> where just two things needed:
>
> (1) The source code
> (2) A compiler
>
> I provided (1) as a single file. If I provided (2), that would be a
> single file too. Otherwise, it would be a single command, like 'gcc
> source.c'.
>

Yes, and how many people use your code? How many have told you that
they had wanted to use gcc for their programming, but found it so hard
to write "gcc -o prog prog.c" that they switched to your compiler so
they could type "bcc prog.c" ?

On 08/08/2023 15:05, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 08/08/2023 12:11, David Brown wrote:
>
>> It is one stupid decision in one compiler that nobody has bothered to
>> fix. At least give it an option to override, but in a form where you
>> don't need to provide a file name. Example:
>>
>> gcc -new prog.c
>
> This would violate the POSIX option guidelines.
>
> gcc -o new prog.c
>
> is far superior in every way.

That doesn't do the same thing. I want the output to be prog.exe, but I
don't want to have to write 'prog' twice.

Your command line will create an output file called 'new'.

'new' refers to 'new rules'.

On 08/08/2023 13:53, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> All I'm hearing is excuses.
>
> I don't think you're hearing anything. Probably the most
> prominent mode seen in your postings is not listening to
> what the other person is saying, and then changing the
> subject.

On 08/08/2023 13:53, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> All I'm hearing is excuses.
>
> I don't think you're hearing anything. Probably the most
> prominent mode seen in your postings is not listening to
> what the other person is saying, and then changing the
> subject.

I get exactly the same feeling.

People will defend a bad C feature to the death, no matter what.
Everything is apparently solved by 'understanding'.

Understanding why that big pile of ugly conditional code exists
/doesn't/ make it all right.

But all anyone here cares about is whether something is right or wrong
according to some section, subsection and paragraph in the C standard.

Unless the subject shifts to tools such as compilers. Then it's a little
bit different:

Whatever gcc does is right. Every other way of doing it is wrong.

Bart <bc@freeuk.com> writes:
>On 08/08/2023 15:05, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 08/08/2023 12:11, David Brown wrote:
>>
>>> It is one stupid decision in one compiler that nobody has bothered to
>>> fix. At least give it an option to override, but in a form where you
>>> don't need to provide a file name. Example:
>>>
>>> gcc -new prog.c
>>
>> This would violate the POSIX option guidelines.
>>
>> gcc -o new prog.c
>>
>> is far superior in every way.
>
>That doesn't do the same thing. I want the output to be prog.exe, but I
>don't want to have to write 'prog' twice.

That's your problem, not ours.

Besides, filename suffixes for executables is silly.

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

> I used CMake for the Baby X resource compiler. It worked on Windows
> and Mac. But it broke on Linux when Ben tested it.

Maybe you were able to conclude that, but I only reported compile
errors. That may have been the fault of CMake, but you never said what
the problem was, only to say that "linux" included <stdint.h>.

> Because it wasn't
> actually passing the "-lm" option to link the math library.

That can't be anything to do with the compile errors that I reported.

--
Ben.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> The problem with the hex-binary form of C is that the representation
>>> of the significant figures varies according to exponent.
>>
>> No necessarily. An implementation can choose to be consistent. In
>> fact, it would take some effort not to be consistent in this regard.
>> Different implementation may choose different representations of the
>> same number, but for a single implementation I would expect the
>> digits to be the same regardless of the exponent.
>
> I understand what you're saying here, and agree with it.
>
> However, there is a subtle point that deserves mentioning. If a
> 'double' value is printed using %a, and the same value is
> converted to a 'long double' and printed using %La, in most cases
> the digits (and exponents) of the outputs will be different.

That does indeed happen in the libc printf I'm using. I am almost
tempted to look at the code to see why that is done. Maybe there is an
obvious reason for it, but I can't think of one off the top of my head.

> This behavior can be confusing when it is first encountered (at
> least, it was confusing for me, until I thought about what's
> going on).

--
Ben.

On 08/08/2023 15:27, David Brown wrote:
> On 08/08/2023 13:36, Bart wrote:
>> On 08/08/2023 12:11, David Brown wrote:
>> > On 04/08/2023 20:25, Bart wrote:
>> >> Besides, with pretty much every other language with a command-line
>> >> build process, if you submit a single source file 'fred.lang', it
>> will
>> >> produce a matching executable 'fred.exe` without needing to be
>> told how.
>> >
>> > Pretty much every other language is not C, and does not have the
>> history
>> > of C or the history of C compilers.
>>
>> That is irrelevant. C compilers like Pelles C, lccwin32, DMC, Tiny C
>> (Windows), MSVC plus mine of course manage to do it properly, despite
>> that history.
>>
>
> Equally, you could argue that all these tools do it wrong - because they
> don't do it the way users of certain other compilers expect.
> As I have said repeatedly, I don't disagree that it could be convenient
> to have an executable name generated automatically from the name of the
> first C file on the list. I just disagree with the idea that such
> behaviour is somehow the only correct or rational choice, or that tools
> that do something different from what /you/ personally prefer are
"wrong".
>
> One difference that may be significant is that most of the tools you
> mention are compilers. The program "gcc" is a driver program - a
> front-end - for a range of tools including compilers for different
> languages and third-party tools such as assemblers and linkers.

'lcc' is also a driver, as is the Pelles C equivalent. But their
internal organisation should not be relevant. Input is a C file, output
is an EXE file, but should that EXE file be called 'silly.ext' (no typo)
in every case unless overridden?

That is obviously silly.

> But if you don't like make, try one of the dozens of alternatives. Or
> write a batch file. Or make your own build program - it's not hard, at
> least for a simple arrangement.

You're misunderstanding something - I don't need nor want 'make'. It's
is just an obstacle to building any software that others use without
thinking.

> Don't forget that compilers are also usually intended for developers.

But you must agree that the needs of an end-user are different? And
simpler. No real need to do tons of testing or analysis: that has
already been done.

So a streamlined build process and a streamlined compiler will work
better with fewer failure points.

>
> Pretty much all software provided as source code will be build using
> build tools. The user will type "install.sh", or "setup.py", or
> "cmake", or "./configure && make && make install", or whatever the
> instructions are for the software. What they will almost /never/ do is
> typing in a series of compiler commands and flags.

I've devised a language with a built-in build system for managing
program source and support files. No external tool is needed.

For more complex requirements beyond that, then yes simple scripting can
be used. But most build processes seem to be about stuff that the
language design should take care of.

> Yes, and how many people use your code? How many have told you that
> they had wanted to use gcc for their programming, but found it so hard
> to write "gcc -o prog prog.c" that they switched to your compiler so
> they could type "bcc prog.c" ?

Doesn't matter.

I have tried to build CPython on Windows. But it doesn't use gcc in that
case, it used MSVC.

The process involved first updating .NET, then downloading VS 2017 (a
90-minute install), then GIT, then SVN, then MS Build Tools, and then it
failed on something else, by which time, several hours and 10GB of
downloads later, I gave up.

Over-complex build systems GO WRONG.

The first obstacle in using 'make' with gcc 10.3.0 is, there IS no
make.exe! (There is mingw32-make.exe which you have to rename or copy.)

gcc 13.2 comes with make.exe, so they learnt something! (I wonder at
what point they decided that actually providing 'make.exe' was a good idea?)

The next one is, how does 'make' know what C compiler I want to use? At
one point I had half a dozen.

The next one is that in most projects, it will fail at some point before
it gets to the end.

You remember the SQLite project? That is 100 files, but supplied as a
single amalgamated C file, plus 2-3 support files, to simplify embedding
it into an application.

Notice that word 'simplify' - not many seem to bother! After all, how
hard can be be it to manage 100 different source file, the make file
will do all the work!

Presumable some difficulty was noticed with doing it the long way. But
your attitude would be that it is the fault of the people having that
difficulty - work harder to understand.

Whether anyone uses my programs or not, I don't care. I get enough of a
kick out of doing it right.

On 08/08/2023 15:34, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 08/08/2023 15:05, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 08/08/2023 12:11, David Brown wrote:
>>>
>>>> It is one stupid decision in one compiler that nobody has bothered to
>>>> fix. At least give it an option to override, but in a form where you
>>>> don't need to provide a file name. Example:
>>>>
>>>> gcc -new prog.c
>>>
>>> This would violate the POSIX option guidelines.
>>>
>>> gcc -o new prog.c
>>>
>>> is far superior in every way.
>>
>> That doesn't do the same thing. I want the output to be prog.exe, but I
>> don't want to have to write 'prog' twice.
>
> That's your problem, not ours.
>
> Besides, filename suffixes for executables is silly.

It would certainly be a problem for Linux, since it would mean typing it
every time:

gcc.exe hello.c -hello

So, OF COURSE you will claim that they are silly anyway!

On 05/08/2023 14:08, Malcolm McLean wrote:
> On Saturday, 5 August 2023 at 12:40:10 UTC+1, David Brown wrote:
>> On 04/08/2023 18:17, Malcolm McLean wrote:
>>> On Friday, 4 August 2023 at 17:05:05 UTC+1, David Brown wrote:
>>>> On 04/08/2023 17:20, Malcolm McLean wrote:
>>>>> On Friday, 4 August 2023 at 16:12:39 UTC+1, David Brown wrote:
>>>>>> On 04/08/2023 16:20, Spiros Bousbouras wrote:
>>>>>>> On Thu, 3 Aug 2023 11:42:36 +0200
>>>>>>> David Brown <david...@hesbynett.no> wrote:
>>>>>>>> When I
>>>>>>>> am looking for software, if I find a possible option and see it is
>>>>>>>> written in ANSI C90, I assume it is some ancient and outdated tool. It
>>>>>>>> /might/ still be useful, but I start with a big negative bias.
>>>>>>>
>>>>>>> That's a strange attitude. If it is written in "old" C then likely it
>>>>>>> was written a long time ago but it certainly doesn't follow that it is
>>>>>>> outdated.
>>>>>> True, of course. For some things, old software is just as good as new
>>>>>> software - if the task hasn't changed, the software does not need to
>>>>>> change. But for other kinds of software you want to be sure that it is
>>>>>> relatively modern, or at least well maintained. That might be for
>>>>>> supporting newer formats (in the case of a "resource compiler"), or
>>>>>> perhaps it is software for which security is a concern. The software
>>>>>> might also be written for older and weaker compilers - using "tricks"
>>>>>> that were popular before, but are undefined behaviour in C and can fail
>>>>>> with modern compilers. Being in an ancient C dialect does not guarantee
>>>>>> that it is outdated, but it is a pointer in that direction.
>>>>>>
>>>>>> I would also have no interest in a "resource compiler" that generated C
>>>>>> files that did not use <stdint.h> or <stdbool.h> types when appropriate,
>>>>>> but perpetuated the inconvenience of home-made types.
>>>>>>
>>>>> It doesn't output homemade types like "u8" for a char. But it doesn't use
>>>>> <stdint.h> or <stdbool.h> types either. It outputs the basic C types.
>>>> That would be useless. Few people doing embedded work have any interest
>>>> in something that turns resources (such as files to be embedded) into
>>>> arrays of "short" or "unsigned long". Use "int16_t", "uint32_t", or
>>>> whatever matches the resource type.
>>>>
>>>> This can be done in a dozen lines of Python scripting, and I get exactly
>>>> what I need. I do so regularly for embedded bitmaps, or static files
>>>> for an embedded webserver, and that kind of thing.
>>>>
>>> Yes, pretty much every C programmer has written a scratch program
>>> to read in a binary and output C source. I can't find a tool that allows you
>>> to get away from that, except the Baby X resource compiler. Whether that
>>> is bad thing, meaning there's no demand for such a tool, or a good thing,
>>> meaning it has a niche no-one else has thought of, I don't know.
>> I think most cases need nothing more than converting a single file into
>> a const array of uint8_t (or unsigned char if you prefer). Anything
>> other than that, and I would not expect a pre-written tool to support
>> what you want because you are likely to have particular needs at the
>> time. When I have embedded fonts, image sequences, directory
>> structures, etc., they have always been targeting a particular format
>> for the application - general purpose or third-party conversion tools
>> would be of no use at all.
>>
> This is the problem of course. The Baby X API expects data in a certain format.
> So all the API functions which operate on images take a 32 bit RGBA buffer
> as an "unsigned char *", and the dimensions as two ints. But another API might
> use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
> images.

It would make a lot of sense to have a program that took data in common
standardised uncompressed forms (like .wav, .bmp) and generated data in
whatever format suits Baby X.

> Of course I could put in a flexible format specifier. But it would rapidly turn into
> a scripting laugage in its onw right. In which case you might as well use Python.

Indeed. You program already looks like that.

>>
>> Some graphics libraries come with "resource compilers" generating
>> results in the format needed for the library. So if your "Baby X" has
>> its own graphics format (or audio format), then a "resource compiler"
>> turning standard formats into this internal format would make sense.
>> But I fail to see how useful it would be for those not using "Baby X".
>>
> Reality is that the resouce compiler is more popular than Baby X. But
> exactly how people are using it, I don't know
>>
>> I also can't imagine why anyone would want to put strings in an xml file
>> instead of just putting them in the source code directly - it gives you
>> no advantages. (If it organised strings and formats for
>> internationalisation and translation, that would be a different matter.)
>>
> There is an "international" tag so you can do this
> <international name = "hello">
> <string language = "english">Hello</string>
> <string language = "french">Bonjour</string>
> <utf8 language = "chinese"> [utf8 here] </utf8>
> </international>
>
> Then it creates a C-callable function which is passed the languafe and returns
> thr right string.
>

That's a horrendous interface for everyone involved. It is hideous for
the programmer writing the XML (like all XML is). It is terrible for
the translators, who want to work with strings in the common language
(usually English) and their own language. It is horrible to use in the
application code. It would be a mess to maintain in source code
repositories.

Seriously, I'm not sure how you could make it worse. Perhaps you could
insist that the translation strings are all held in a MS Excel format
spreadsheet?

Did you even think about how people were supposed to use it, or how
international programs are developed?

I appreciate what you are trying to do with the tool, I just don't think
you have considered what might be the best way for people to use it.

On 08/08/2023 16:18, David Brown wrote:
> On 05/08/2023 14:08, Malcolm McLean wrote:
>> Then it creates a C-callable function which is passed the languafe and
>> returns
>> thr right string.
>
> That's a horrendous interface for everyone involved. It is hideous for
> the programmer writing the XML (like all XML is). It is terrible for
> the translators, who want to work with strings in the common language
> (usually English) and their own language. It is horrible to use in the
> application code. It would be a mess to maintain in source code
> repositories.
>
> Seriously, I'm not sure how you could make it worse. Perhaps you could
> insist that the translation strings are all held in a MS Excel format
> spreadsheet?
>
> Did you even think about how people were supposed to use it, or how
> international programs are developed?
>
>
> I appreciate what you are trying to do with the tool, I just don't think
> you have considered what might be the best way for people to use it.

I didn't understand all the purposes of the tool (I'm not going to use
Baby X).

It just looked like something that takes a media file and turns it into
a block of C code suitable for embedding.

When I tested it, it turned out I needed an XML file (as you say, truly
horrible to work with). I had to use the example provided and tweak it.

A simpler interface is just to accept the name of one media file, and
turn that into a .c file (with the same name!). Any resizing options etc
can be provided on the command line.

Or that can be done via an alternate front-end module built into its own
executable, keeping the Baby X functionality separate.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> The problem with the hex-binary form of C is that the representation
>>>> of the significant figures varies according to exponent.
>>>
>>> No necessarily. An implementation can choose to be consistent. In
>>> fact, it would take some effort not to be consistent in this regard.
>>> Different implementation may choose different representations of the
>>> same number, but for a single implementation I would expect the
>>> digits to be the same regardless of the exponent.
>>
>> I understand what you're saying here, and agree with it.
>>
>> However, there is a subtle point that deserves mentioning. If a
>> 'double' value is printed using %a, and the same value is
>> converted to a 'long double' and printed using %La, in most cases
>> the digits (and exponents) of the outputs will be different.
>
> That does indeed happen in the libc printf I'm using. I am almost
> tempted to look at the code to see why that is done. Maybe there is an
> obvious reason for it, but I can't think of one off the top of my head.

It happens because of the formats of double and long double. For
most non-zero values (and not inf or NaN), a double has 52 bits
of significand plus an implied '1' at the top, giving 53 bits
overall. Converting to long double gives 64 bits of significand
only now the high-order '1' is explicit (ie, 64 bits overall).
So double has one bit for the leading digit (always 1) plus 13
groups of four bits, whereas long double has four bits for the
leading digit (always between 8 and F) plus 15 groups of four
bits.

If you see a %a output whose leading digit is between 8 and F,
probably what was done is the double value was converted to a
long double, so the long double value could just be funneled
through the code for the long double case.

On Tuesday, 8 August 2023 at 15:39:21 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > I used CMake for the Baby X resource compiler. It worked on Windows
> > and Mac. But it broke on Linux when Ben tested it.
> Maybe you were able to conclude that, but I only reported compile
> errors. That may have been the fault of CMake, but you never said what
> the problem was, only to say that "linux" included <stdint.h>.
>
The MP3 decoder included a few standard headers, then typedefed
types like uint8_t, to match <stdint.h>. It works fine on Windows and Mac
because the standard headers don't define those types. But on Linux,
they obviously include <stdint.h>, whch I believe they are allowed to
do, and so the code broke.
> > Because it wasn't
> > actually passing the "-lm" option to link the math library.
> That can't be anything to do with the compile errors that I reported.
>
So the link error came out in the wash. Many thanks anyway for drawing my
attention to the problem. It's genuinely appreciated.

On 07/08/2023 17:40, Malcolm McLean wrote:
> On Monday, 7 August 2023 at 16:13:16 UTC+1, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>>> On 07/08/2023 12:41, Richard Damon wrote:
>>>> On 8/7/23 5:35 AM, Bart wrote:
>>
>>>>> Do you not see the problem of a hex format, which is already confusing
>>>>> because it is hex, representing the same value in different ways?
>>>>>
>>>>> In decimal, pi is always going to involve the digits 314159... with
>>>>> the decimal position depending on the exponent.
>>>>>
>>>>> With %A format (I've made 0x and p lower case for clarity; another
>>>>> issue), I can get either:
>>>>>
>>>>> 0xC.90FDAA22168Cp-2
>>>>>
>>>>> or:
>>>>>
>>>>> 0x1.921FB5p+1
>>>>>
>>>>> That's perfectly alright!
>>>>
>>>> Yes, it just like you can represent 0.5 as 5/10, 1/2, or even 2/4ths.
>>>
>>> We're not talking about fractions or rationals.
>> That's exactly what we are talking about. What do you think
>> 0x1.921FB5p+1 is if not a rational number?
>>
>> Floating point numbers are rationals, but since they are usually
>> represented internally in binary, they are hard to represent exactly in
>> base 10. The %a format is there to solve that problem. Humans don't
>> read the output except in rare cases. I used to when I was working with
>> interval arithmetic, but that was for debugging.
>>> The problem with the hex-binary form of C is that the representation of the
>>> significant figures varies according to exponent.
>> No necessarily. An implementation can choose to be consistent. In
>> fact, it would take some effort not to be consistent in this regard.
>> Different implementation may choose different representations of the
>> same number, but for a single implementation I would expect the digits
>> to be the same regardless of the exponent.
>>>> Your problem with the Hex representation is that you don't understand
>>>> what its purpose is. IT isn't to allow you to compare two numbers, but
>>>> to EXACTLY (and faiy efficiently) represent a floating point number.
>>>
>>> Why is not possible to do that if the exponent represents hex digits
>>> rather than binary ones?
>> That's a confused remark. Representing the exponent in hex digits makes
>> no difference. Different implementations could still choose different
>> ways to write the same number. Your suggestion is, I think, to write
>> the convert the binary exponent into a power of 16. That could be done
>> even if the resulting exponent is written in decimal, but I think you
>> advocate for both: writing the binary exponent as a poser of 16 and to
>> represent that power in hex digits.
>>
>> But I agree with the underlying point of your remark -- I don't think
>> there is any reason why your alternative representation could not be
>> exact and fairly efficient on most hardware.
>>> For example, I want to call the printf() function from the C runtime via an
>>> FFI; what format code do I use: is it %d, %ld or %lld?
>>>
>>> But those 'l' modifiers are in terms of C types, which are meaningless in
>>> my language;
>> That is not C's fault; they are intended for C's types, not yours.
>>> (Try and print int64_t, it will be either %ld or %lld!)
>> You should print an int64_t using the PRId64 macro or by converting it
>> to long long and using %lld. After so many years here how can you still
>> be having trouble knowing how to print a value from your language?
>>
> The advantage of C is that it is very flexible.
> What you can do is this.
>
> /*
> questionformat - a printf-style format string with %? escapes for unknown
> formats.
> ... - the unknown types, in pairs giving type and size.
> types: QFMT_REAL, QFMT_SIGNEDINTEGER, QFMT_UNSIGNEDINTEGER.
> sizes - sizeof() value of type
>
> e.g
> char *fmt = formatstring("Hello %s your salary is %?, ycur payrollid %?\n"
> QFMT_REAL, sizeof(salary_t),
> QFMT_UNSIGNEDINTEGER, sizeof(payrollid_t));
> printf(fmt, employee.name, employee.salary, employee.payrollid);
> */
> char *getformatstring(const char *questionformat, ....)
>
>

Surely a smarter way (if you want this kind of thing) would be to
combine _Generic and variadic macros, so that you can write:

Print("Hello ", employee.name, " your salary is ", employee.salary);

Or perhaps you could just have your variadic macro convert all
parameters to a common 64-bit union type (combining uint64_t, double and
const void*) before passing it on to your alternative printf-style
function. There are many possibilities that would not be as clumsy as this.

They might involve some ugly macros in the implementation, but you only
need to make these once, and it's the appearance in user code that matters.

On 08/08/2023 16:09, Bart wrote:
> On 08/08/2023 15:27, David Brown wrote:

> I've devised a language with a built-in build system for managing
> program source and support files. No external tool is needed.
>
> For more complex requirements beyond that, then yes simple scripting can
> be used. But most build processes seem to be about stuff that the
> language design should take care of.

I should say that if I was writing an original C program with multiple
modules, and was supplying it with those separate modules, the build
process I'd choose is something that seems to be neglected: @ files.

These are files of options that most C compiles seem to accept. An @
file is basically a list of module names.

They can contain options too, but for portability it should be ones
shared across compilers. Then building a project looks like this:

gcc @project

where 'project' contains all the inputs needed.

This will build all modules, which is what is needed for a one-time
build anyway.

Bart <bc@freeuk.com> writes:
>On 08/08/2023 15:34, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 08/08/2023 15:05, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 08/08/2023 12:11, David Brown wrote:
>>>>
>>>>> It is one stupid decision in one compiler that nobody has bothered to
>>>>> fix. At least give it an option to override, but in a form where you
>>>>> don't need to provide a file name. Example:
>>>>>
>>>>> gcc -new prog.c
>>>>
>>>> This would violate the POSIX option guidelines.
>>>>
>>>> gcc -o new prog.c
>>>>
>>>> is far superior in every way.
>>>
>>> That doesn't do the same thing. I want the output to be prog.exe, but I
>>> don't want to have to write 'prog' twice.
>>
>> That's your problem, not ours.
>>
>> Besides, filename suffixes for executables is silly.
>
>It would certainly be a problem for Linux, since it would mean typing it
>every time:
>
> gcc.exe hello.c -hello
>
>So, OF COURSE you will claim that they are silly anyway!

Actually, they (file suffixes) have been a security problem since day one
on Windows.

I've been using C since 1979,

$ cc -o ls ls.c

has been a useful paradigm for a half century; if you don't like it, that's
your problem.

Note that the vast majority of real production C code consists of multiple
source files (hundreds in some cases, often in multiple languages and
sometimes compiling C code generated (e.g. lex, yacc) by other utilities);
it is unlikely that even you would manually type a compilation command line
with hundreds of source files.

On Tuesday, August 8, 2023 at 2:05:48 PM UTC+3, Bart wrote:
> On 08/08/2023 03:21, Richard Damon wrote:
> > On 8/7/23 8:28 PM, Bart wrote:
> >> My view is that C's print-format system is not fit for purpose. The
> >> formatting is OK, it is needing to specify types that is the problem.
> >
> > which is EXACTLY the arguement that got us the C++ stream << operator.
> That feature is so bad it makes using printf preferable! Is it really
> that hard to just be able to write 'print x' ?
> > If you want to do that in C, you can, just define a generic "print"
> > function that defines version for each fundamental type, and call that.
> >
> > You don't seem to understand that C is based on the assumption that the
> > programmer actually knows what he is doing, not hiding behind a mass of
> > abstractions.
> You don't get my point. The programmer might not know for sure the type
> of a complex expression, and certainly does not want to keep updating
> dozens of printf formats across the codebase as global declarations change.
>
> Right now I don't know how to print a clock() result for example, and to
> keep inventing special formats like %zu is crass.
>
> *I* can just write:
>
> println a, b, c
>
> So can a dozen other languages (even from the 1960s!). I can change the
> types of a, b, c, and it still works. I can print c, b, a and it still
> works.
>

What does it do?
I'd guess, it prints a, b and c, each in default format corresponding to respective
types, each on the separate line?
In theory it's nice to have something like that in the language. But in practice I very
rarely need thing printed like that, one per line and in default format. One number
instead of three would be a little more common, by just a little.

> I can even just do 'print clock()'!

Now you hit a real point.
But on the second thought I realize that I don't know what default format I'd
want in this case.

>
> In C YOU CAN'T DO THAT. You need to dig up the types of each expression
> and apply the right format. In this VERY simple case, it MIGHT be:
>
> printf("%lld " PRId64 " %s", a, b, c);
>
> But now you have an extra maintenance headache.
>
> (In all cases, printing gets untidy when you need to do necessary
> formatting, but only C incorporates types into the formatting.)
> >> It gets tricky when using sprintf say from another language, which is
> >> then transpiled to actual C.
> >
> > And why doesn't that other language implement a better print
> > functionality itself?
> It does, but ultimately it needs to do I/O, and I've been using C's
> printf for that since the mid-90s, because it was simpler than using
> WinAPI. I've since forgotten how do it with WinAPI.
>
> For that purpose, I only need to use %c and %s. (For floats, I use
> sprintf with %e %f %g, do any formatting, then use printf with %s if I
> need output.)
>
> So most of the time it is not an issue (other than, if using C
> transpilation, there is still the problem of C's char* type not existing
> in my language, nor any other).
>
> Sometimes however, during bootstrapping or developing a new compiler, it
> might not yet support the 1000 lines of code needed to implement my
> Print routines, or there are codegen bugs, or I'm trying to keep test
> code absolutely minimal, then I will use printf.
>
> Or I might use it from my dynamic scripting language. I just use %ll
> since everything is 64 bits. Or I can test that other matter:
>
> printf("%A", pi) # interpreted code
>
> shows:
>
> 0X1.921FB5P+1
> > You are using C as a "portable assembler", but you don't actually seem
> > to want to understand the assembly language and are complaining because
> > the machine doesn't implement the fancy instructions you want to use.
> Exactly. C *IS* used extensively as a portable assembler, as an
> intermediate or target language, and there you don't want its UBs,
> foibles and quirky type system to get in the way, because source
> language and final targets are better defined than in C.
>
> This is an important use-case which should not be forgotten.

On Tuesday, August 8, 2023 at 5:06:04 PM UTC+3, Scott Lurndal wrote:
> Bart <b...@freeuk.com> writes:
> >On 08/08/2023 12:11, David Brown wrote:
>
> >It is one stupid decision in one compiler that nobody has bothered to
> >fix. At least give it an option to override, but in a form where you
> >don't need to provide a file name. Example:
> >
> > gcc -new prog.c
> This would violate the POSIX option guidelines.
>
> gcc -o new prog.c
>
> is far superior in every way.

Longer.
Less of obvious, at least for persons that didn't read
"POSIX option guidelines" which to the first level of approximation
includes all potential users.
So even if superior then *not* in every way.

On Tuesday, 8 August 2023 at 16:18:49 UTC+1, David Brown wrote:
> On 05/08/2023 14:08, Malcolm McLean wrote:
>
> > This is the problem of course. The Baby X API expects data in a certain format.
> > So all the API functions which operate on images take a 32 bit RGBA buffer
> > as an "unsigned char *", and the dimensions as two ints. But another API might
> > use an opaque "IMAGE" structure. Or another system might have 16 bit r5g5b5a1
> > images.
>
> It would make a lot of sense to have a program that took data in common
> standardised uncompressed forms (like .wav, .bmp) and generated data in
> whatever format suits Baby X.
>
"Data" means, "that which is given". People programming applications are given
resources in many formats. They might steal a PNG from the web, get a JPEG
commissioned from a paid artist, knock up their own SVG.
Now of course it's possible to convert all these into a common format like PNG
which is powerful enough to hold all thse formats without loss. But you've lost
the link with the original data. So when the artist comes back with a second
version of the JPEG, you've got to run ImageMagick again. And I don't have
ImageMagick installed on the Mac I'm writing this on (there's a program called
sips which does similar things).
A resouce pipeline with lots of stages, each one requiring a separate third party
program, is quite fragile. It works for as long as your Linux machine is all set up
with the dependencies, which will be the case for the duration of the project.
But if you archive it, and dust it off years later, will things still be intact? And
will you know which are the intermediate files, and which are the original data?
>
> > Of course I could put in a flexible format specifier. But it would rapidly turn into
> > a scripting laugage in its onw right. In which case you might as well use Python.
>
> Indeed. You program already looks like that.
>
No it doesn't. There's a very simple xml list of resources, and one or two attributes
to control the output. It's nothing like a script. However to be fair I do suggest diving
into the source if you want to customise it. The users will be C programmers, after
all.
> >
> > There is an "international" tag so you can do this
> > <international name = "hello">
> > <string language = "english">Hello</string>
> > <string language = "french">Bonjour</string>
> > <utf8 language = "chinese"> [utf8 here] </utf8>
> > </international>
> >
> > Then it creates a C-callable function which is passed the languafe and returns
> > thr right string.
> >
>
> That's a horrendous interface for everyone involved. It is hideous for
> the programmer writing the XML (like all XML is). It is terrible for
> the translators, who want to work with strings in the common language
> (usually English) and their own language. It is horrible to use in the
> application code. It would be a mess to maintain in source code
> repositories.
>
> Seriously, I'm not sure how you could make it worse. Perhaps you could
> insist that the translation strings are all held in a MS Excel format
> spreadsheet?
>
> Did you even think about how people were supposed to use it, or how
> international programs are developed?
>
You might be right about that. We considered internationalisation at
work (we make tools for artists), but the customers said they were
happy with English, and it was such a bag of worms that we rejected
the idea. So I've no experience. Part of the reason for discussing it here
is that other people might have such experience.
You can't really support Unicode but not support internationalisation,
however.
>
> I appreciate what you are trying to do with the tool, I just don't think
> you have considered what might be the best way for people to use it.
>
It's a resource compiler for Baby X. There's no good way of getting images and
fonts into Baby X programs, other than using the resource compiler. Just as
there's no good way of getting images and fonts into Windows programs without
using the Windows resource compiler. But because the Baby X resource compiler
produces C source instead of a binary blob, you don't have to use it with Baby X.

But I'm not deliberately targetting non-Baby X users with v1.2, though the <utf16>
tag is maybe a concession to non-Baby X use (Baby X uses UTF-8 throughout).
As you have pointed out, there are a whole host of issues to consider before
doing this properly. So it's something for a future version, not v1.2.

On 07/08/2023 23:17, Bart wrote:
> On 07/08/2023 13:16, David Brown wrote:
> > On 05/08/2023 15:17, Bart wrote:
> >> On 05/08/2023 03:50, Tim Rentsch wrote:
> >>> Richard Damon <Richard@Damon-Family.org> writes:
> >>>
> >>>> On 8/4/23 10:25 AM, Bart wrote:
> >>>>
> >>>>> [...]
> >>>>
> >>>> Maybe your problem is you dont understand [...]
> >>>
> >>> Bart's problem isn't that he doesn't understand.  Bart's
> >>> problem is that he doesn't _want_ to understand.
> >>
> >> Bart is the kid who questions the Emperor's new clothes.
> >>
> >
> > No, that (like so much else) is just in your imagination.
>
> You've heard of the term 'code smell'? Well stuff like that just
> completely stinks.
>
> 50 years' plus and a /systems/ program language is incapable of
> describing a simple machine type without making a dog's dinner of it?
>
> (It doesn't even create the type; it's making it possible for some other
> code to create the type!)
>
>
> > Everyone in this thread is perfectly aware of the short-comings of C.
> > Everyone knows that plenty of the parts of C standard library headers is
> > a mess (it's not just Newlib, though that might be one of the messiest).
> >   The rest of us understand why, and understand that it doesn't matter
> > for people using C.
> >
> > You are not telling anyone anything new, nor exposing hidden secrets.
>
> OK. So you don't think there is, right now, any other shorter solution
> to that set-up code which uses an #if-#else ladder to define __int32_t?
> Bear in mind there might be 7 more lots of code like that to cover all 8
> types!
>

I really don't get why you insist on making stuff up. I haven't said
anything like that. Maybe there is a shorter and neater way to achieve
the needs of Newlib in its headers - maybe there isn't. I haven't
studied the code or the targets of Newlib.

> And you don't think that C99 could have been done any differently to
> make such code shorter, or unnecessary?

Again, I have said nothing of the kind. I know that if /I/ had been
designing C99 (or any other part of C) for my own personal use, I'd have
done many things differently. Is that what you'd like to hear?

Just like the original C standards, C99 was somewhat of a compromise,
with an emphasis on supporting existing code (written to C90 or K&R
standards, or using extensions from existing compilers), taking into
account existing compilers and their extensions and uses, and also
considering C++ usage when it fitted with C. Ease of implementation in
compilers and libraries was very low down the list of priorities.

Of course the priorities and trade-offs could certainly have been made
differently, and you'd have different results. Who knows if that would
have been a good idea or a bad idea? Certainly the number of lines and
type handling in the headers of one particular C library is no way to judge.

On Tuesday, August 8, 2023 at 5:16:14 PM UTC+3, Bart wrote:
> On 08/08/2023 13:22, Richard Damon wrote:
> > On 8/8/23 7:05 AM, Bart wrote:
> >> On 08/08/2023 03:21, Richard Damon wrote:
> >> > On 8/7/23 8:28 PM, Bart wrote:
> >> >> My view is that C's print-format system is not fit for purpose. The
> >> >> formatting is OK, it is needing to specify types that is the
> problem.
> >> >
> >> > which is EXACTLY the arguement that got us the C++ stream <<
> operator.
> >> That feature is so bad it makes using printf preferable! Is it really
> >> that hard to just be able to write 'print x' ?
> >>
> >> > If you want to do that in C, you can, just define a generic "print"
> >> > function that defines version for each fundamental type, and call
> >> that.
> >> >
> >> > You don't seem to understand that C is based on the assumption that
> >> the
> >> > programmer actually knows what he is doing, not hiding behind a
> >> mass of
> >> > abstractions.
> >>
> >> You don't get my point. The programmer might not know for sure the
> >> type of a complex expression, and certainly does not want to keep
> >> updating dozens of printf formats across the codebase as global
> >> declarations change.
> >
> > Then they are using the wrong tool.
> What tool did you have in mind? Do you mean that an IDE will tell you
> the types of the expressions, or write the format codes for you?
>
> That strikes me as the same argument that you can use CDECL to get round
> abstruse C type specs. If the tool can do it, why doesn't the compiler?
> Or the language.
> > C is designed to be used when you know, at least in general, what you
> > are working with.
> >
> >>
> >> Right now I don't know how to print a clock() result for example, and
> >> to keep inventing special formats like %zu is crass.
> >>
> >> *I* can just write:
> >>
> >> println a, b, c
> >
> > So, why don't you?
> I do. It's lovely. The question is, why are a million users of C denied
> that?
> > is the problem that you don't know how to translate that into C?
> >
> >>
> >> So can a dozen other languages (even from the 1960s!). I can change
> >> the types of a, b, c, and it still works. I can print c, b, a and it
> >> still works.
> >>
> >> I can even just do 'print clock()'!
> >>
> >> In C YOU CAN'T DO THAT. You need to dig up the types of each
> >> expression and apply the right format. In this VERY simple case, it
> >> MIGHT be:
> >
> > Because C is a lower level, and targeted to be more efficiet, than those
> > other languages.
>
> Sorry, but that is rubbish. My 'M' language is also low level, but
> somehow manages to have a proper print. And it's not dead slow either:
>
> A loop which prints the numbers up to 10 million (redirected to a file
> to remove display overheads), takes 1.8 seconds in my language, and 3.2
> seconds using gcc 13.2 -O3. bcc/tcc take 2.4 seconds.
>
> (My library is faster, despite the int->text code being unoptimised,
> because of buffering. But then maybe gcc's printf is also buffered
> internally. Which one is cheating more? I know mine won in this case!)

Sounds like gcc under mingw64/msys64.
It uses old Microsoft's DLLs (from Visulat Studio 2013 or something like that)
for C RTL. For many tasks it's o.k. but for few others slow or problematic
in a different ways.
So, you can't blame 'C' or gcc for this particular slowness.
You can't even blame Microsoft, because C RTL supplied with their less
ancient compilers prints integers much faster.
And you can't blame mingw64 maintainers because they are mostly
volunteering.

> >>
> >> printf("%lld " PRId64 " %s", a, b, c);
> >>
> >> But now you have an extra maintenance headache.
> >>
> >> (In all cases, printing gets untidy when you need to do necessary
> >> formatting, but only C incorporates types into the formatting.)
> >>
> >>
> >> >> It gets tricky when using sprintf say from another language,
> which is
> >> >> then transpiled to actual C.
> >> >
> >> > And why doesn't that other language implement a better print
> >> > functionality itself?
> >>
> >> It does, but ultimately it needs to do I/O, and I've been using C's
> >> printf for that since the mid-90s, because it was simpler than using
> >> WinAPI. I've since forgotten how do it with WinAPI.
> >
> > So, your problem is that you aren't willing to do the work yourself.
> What problem is this? I've been implementing 'proper' PRINT in languages
> since as far back as 1981.
>
> At some point, nearly 20 years later, I switched from OS to C functions
> for low-level I/O, for consoles or files. For Printing to printers,
> images, windows and strings, I still handled that.
> > So again, the problem is you are using the wrong tool or your language
> > is incomplete.
> The problem is that you don't have a clue what the problem is.
>
> There is no tool, and no feature in my language (other than turning it
> into C), that will fix the problem that C's 'char*' is so unique.
>
> Usually you can ignore that if using C's library purely via a binary
> interface, but if generating C code, you will see issues. The solutions
> are ugly and ungainly.
>
> Try it and see!
> > But to use C as a portable assembler, you need to use it as an
> > assembler, and that means understanding the nature of the "assembly
> > language".
> An assembly language which has a million more rules, special cases and
> UBs than any real assembler!
>
> In x64 assembly, I can write a floating point value to a 64-bit memory
> location, and read it back as an integer, with no issues:
>
> movq [fred], xmm0
> mov rax, [fred]
>
> C makes that undefined - maybe.
> > IF you are concerned about efficient outputing of valuse, you build a
> > family of generic "print" functions that use the right version for the
> > type given, and let the complier figure it out. Just means you can't put
> > everything in one statement. (but this is intermediary code, so doesn't
> > really need to be totally readable).
> This is exactly what I do behind the scenes of my language. And another
> reason why I sometimes use 'printf', since it produces long sequences of
> function calls which obscure minimal test code.
>
> The advantage of printf also is that it is outside my language, so its
> implementation code doesn't intrude.

On 08/08/2023 16:31, Bart wrote:
> On 08/08/2023 13:53, Tim Rentsch wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> All I'm hearing is excuses.
>>
>> I don't think you're hearing anything.  Probably the most
>> prominent mode seen in your postings is not listening to
>> what the other person is saying, and then changing the
>> subject.
>
> On 08/08/2023 13:53, Tim Rentsch wrote:
> > Bart <bc@freeuk.com> writes:
> >
> >> All I'm hearing is excuses.
> >
> > I don't think you're hearing anything.  Probably the most
> > prominent mode seen in your postings is not listening to
> > what the other person is saying, and then changing the
> > subject.
>
> I get exactly the same feeling.
>
> People will defend a bad C feature to the death, no matter what.
> Everything is apparently solved by 'understanding'.
>
> Understanding why that big pile of ugly conditional code exists
> /doesn't/ make it all right.
>
> But all anyone here cares about is whether something is right or wrong
> according to some section, subsection and paragraph in the C standard.
>
> Unless the subject shifts to tools such as compilers. Then it's a little
> bit different:
>
> Whatever gcc does is right. Every other way of doing it is wrong.
>

If you want to program in C, understanding the language is vital. If
you want to use a compiler, understanding how to use it is vital.

Your posts are a mix of misunderstandings and hatred - most of it
blaming the wrong thing. No one here particularly cares about your
personal opinions, and certainly no one can change them, but we do try
to help clear up your misunderstandings.

It is rare for others to express personal opinions directly here - only
occasionally do you see people writing "I'd prefer it if C were defined
like this...". We are mostly much more concerned about how C is
specified, and how it can be used. Similarly, people want to know how
compilers can be used - that is much more important that /why/ they work
in a particular way. Sometimes, however, it is also interesting to look
at the historical prospective to see why particular decisions were made
in the design of C (or compilers).

But do not mistake an understanding of the language and tools for an
unbridled fanboy love of all aspects of C. Most of us have things we
dislike about the language and common tools - though most of us enjoy
using C, or we'd probably not be in this group.

On Tuesday, 8 August 2023 at 17:18:10 UTC+1, David Brown wrote:
>
> But do not mistake an understanding of the language and tools for an
> unbridled fanboy love of all aspects of C. Most of us have things we
> dislike about the language and common tools - though most of us enjoy
> using C, or we'd probably not be in this group.
>
Yes. I'm a great fan. I woke up at about 4.00 last night and spent the
whole early morning chasing memory leaks. (I finally managed to
get valgrind working on a virtual Linux machine). Half of them were
due to failure to free a string holding a file extension, usually only of
five bytes (I included the dot, and the null, and three for the extension
itself). I did think, why didnt I just use C++ and an std::string. Or even
just knock up some Python scripts.

But the thing is, the C code will likely last practically forever. The C++
code won't. The CMake script I wrote a few days ago has already been
deprecated, by the way. It contains a minimum version, and the CMake
people plan to break compatibility with that version. So it's a good job
the program can be compiled with a single simple commandline call to gcc.

On 08/08/2023 17:09, Bart wrote:
> On 08/08/2023 15:27, David Brown wrote:

>
> > But if you don't like make, try one of the dozens of alternatives.  Or
> > write a batch file.  Or make your own build program - it's not hard, at
> > least for a simple arrangement.
>
> You're misunderstanding something - I don't need nor want 'make'. It's
> is just an obstacle to building any software that others use without
> thinking.

/You/ are misunderstanding something. If you need to do something, and
there are tools easily available that let you do it, but you refuse to
use those tools, then you can't expect any sympathy from others.

gcc is a compiler (or a driver program, or a collection of compilers,
depending on what part of it you are talking about). It was not built
to spoon-feed lazy or ignorant developers. And it does not contain a
build tool.

>
> > Don't forget that compilers are also usually intended for developers.
>
> But you must agree that the needs of an end-user are different? And
> simpler. No real need to do tons of testing or analysis: that has
> already been done.
>

Yes, I agree.

> So a streamlined build process and a streamlined compiler will work
> better with fewer failure points.
>

Yes. So use a build tool.

>
> I have tried to build CPython on Windows. But it doesn't use gcc in that
> case, it used MSVC.
>
> The process involved first updating .NET, then downloading VS 2017 (a
> 90-minute install), then GIT, then SVN, then MS Build Tools, and then it
> failed on something else, by which time, several hours and 10GB of
> downloads later, I gave up.
>
> Over-complex build systems GO WRONG.
>

CPython is a huge project, unsuitable for amateurs to build. That's why
almost nobody builds it themselves.

Windows is a huge mess, unsuitable for serious development work. That's
why so many people (including lots at Microsoft) prefer *nix systems for
development.

You are combining a massive project with a shitty OS and a totally
incompetent developer, and expecting things to go smoothly. It's hardly
a fair test.

> The first obstacle in using 'make' with gcc 10.3.0 is, there IS no
> make.exe! (There is mingw32-make.exe which you have to rename or copy.)

gcc never has, and never will, ship with any version of "make".

You might have acquired them together from some third-party packaging
system. If you don't like the way that packaging was done, take it up
with them. Maybe ask for a refund.

>
> gcc 13.2 comes with make.exe, so they learnt something! (I wonder at
> what point they decided that actually providing 'make.exe' was a good
> idea?)
>

gcc never has, and never will, ship with any version of "make".

Look, you /know/ this stuff. You've been told countless times. This is
why people call you a troll - you can't be /that/ stupid.

> The next one is, how does 'make' know what C compiler I want to use? At
> one point I had half a dozen.

Clearly these "computah" things are a bit advanced for you. May I
recommend an iPad? Or a TV? Because now I am sure you are trolling.

On 2023-08-08, Bart <bc@freeuk.com> wrote:
> People will defend a bad C feature to the death, no matter what.
> Everything is apparently solved by 'understanding'.

No; people are just defending the correct interpretation and
understanding of the bad C feature, and why you can't just change it
on a whim.

You're obviously not here to follow the newsgroup, otherwise it would be
painfully obvious that it's quite full of language criticism. Not
everyone in this newsgroup, or thread, agrees with every old or new
thing in C.

You've acknowledge that it was very hard to get your C compiler to
just drop an executable for the sqlite3.c source file of over 200
kilobytes.

But you somehow assume that it's easy for the rest of the C world to
turn on a dime with any random improvement dictated by a new spec.

> Understanding why that big pile of ugly conditional code exists
> /doesn't/ make it all right.

Understanding it not making it right doesn't make it all right
to deliberately misunderstand.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-08-08, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> "Data" means, "that which is given". People programming applications are given

Or, well, "those which are given", if we are going to be pedantic.

"Datum" is that which is given.

:)