On 7/17/23 12:26, Bonita Montero wrote:
> Am 13.07.2023 um 07:37 schrieb Blue-Maned_Hawk:
>>
>> ​Ain't nothing gonna dethrone C until a total revolution of the modern
>> computing ecosystem; in other words, replacing C would require
>> replacing everything else all at once.
>
> C has already been dethroned many times.
​I think you and i have different definitions of "dethrone" here.
--
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't
have shit in Thunderbird 😩

On 18/07/2023 03:25, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> OK. But in that case why is C's so-called portability touted so much?
>
> Who touts it? Picking an old version of C, and sticking to the standard
> can result in reasonably portable programs, but the whole notion is
> fraught with misunderstandings and is not easy to define. C is often
> thought of as being very portable because almost every platform has a C
> compiler, but writing highly portable is very hard and few people know
> how to do it well. Does that mean that C is portable or does it mean it
> isn't? The question is not an easy one to answer.

So why pick on [criticise] a method of accessing the top bit of a 32-bit
word that is going to work on all platforms of interest?

What's really going on is that because that method might be tagged as UB
(/because/ of various obscure architectures where it won't work), we're
not allowed to use it in cases (perhaps the majority) where there would
be no problem.

> C has changed quite a bit too

C's changes are minor. Fortran changed from being unstructured, to
structured, among other major differences.

>>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
>>> -fsanitize=undefined -Wbad-function-cast \
>>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral
-Wcast-align \
>>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>>>
>>> so I can see problems as early as possible.
>>
>> So you're using a version of the language defined by those options.
>
> That's what every compiler ever written does: process a language defined
> by the author(s), the options used and the bugs in the implementation.

gcc allows for myriad different dialects, and that's before extensions
are considered.

My bcc compiler allowed for just two: there was an `-old` switch to
enable features I didn't want to have, but were necessary to compile
some existing programs.

(One consequence of gcc allowing deprecated features by default is that
uses of those features are not curtailed; they are perpetuated.)

> I really don't know what you hope to gain by saying obvious things like
> this other than to (incorrectly) imply that C -- the language -- is not
> defined by it's defining documents -- the ISO standards -- but by
> compiler options.

I've given examples in the past where the same C program either:

* Passed with 0 lines of errors or warnings

* Passed with 28,000 lines of warnings and notes (on a 40Kloc input)

Or it could fail if you were to use -Werror too. In the case where it
produced 28,000 lines, you had to peruse all those lines to find out if
there was an 'error:` line, to discover if it had passed or not.

All I want to know is: is my program a valid C program, but gcc will not
tell me; apparently *i* have to tell *it* how strictly it should treat
my code!

This is like someone taking an exam, telling the examiner how strictly
they should mark their paper.

I think you're just not seeing it. A compiler should take more
responsibility for deciding a valid program, or the language should do
so if it merely leaves things to the implementation.

> Fortunately, gcc is a quality compiler and these options make the
> language it accepts as close to ISO standard C (the 2011 version) as I
> can get it, but there will always be bugs and misunderstandings.

With your options I managed to still produce an executable for this:

int main() {main(1, 2.0, "three", main, main, main();}

My bcc compiler failed it /unless/ I specified '-old'.

Without any options, gcc said nothing about it (a quality compiler indeed!).

>> BTW I can't remember using any options when compiling Fortran.
>
> Really? Odd. I remember needing multiple JCL cards to invoke the IBM
> 360 FORTRAN compiler, but you didn't get much choice about the language.
> It implemented IBM's interpretation of FORTRAN IV and you were stuck
> with it, though you could choose to write in a more portable subset.

This the manual for Fortran IV for RSX11M:

https://usermanual.wiki/Document/RSX11MV1FortranIVUsersGuide.3451439411/view

Compiler options are on page 1-6. There aren't many, and only one
affects the behaviour of the program: /I4 (which is default) to use an
i32 implicit type for integers instead of i16.

The other Fortran IVs I used ran on mainframes; I can't remember the
details.

On 18/07/2023 05:27, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> (In the case of Fortran, I remember using machine-specific types such
>> as INTEGER*4 (i32) in 1979; was there anything similar in C before
>> C99?
>>
>> Funny that the non-low-level language had machine types, and
>> close-to-the-metal C didn't!
>
> So your complaint is that C has fixed-width types *now*, but didn't
> acquire them until 24 years ago? It's difficult to imagine any
> explanation that would satisfy you.
>
> And you're referring to the intN_t types as "machine types"?
> Why do you call them that?

OK, so, N has the values of 8, 16, 32, 64, which by some remarkable
coincidence are also the bit-widths supported by most current hardware,
but that doesn't make them machine types?

On 18/07/2023 08:33, Chris M. Thomasson wrote:
> On 7/18/2023 12:26 AM, David Brown wrote:
>> On 18/07/2023 00:01, Chris M. Thomasson wrote:
>>> On 7/17/2023 3:01 PM, fir wrote:
>>>> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
>>>>>   C is a  high level language.
>>>>
>>>> i propose to say c is mid-level language.. i would say its closer to
>>>> low-lewel than high-level
>>>
>>> I tend to agree with that.
>>>
>>
>> I don't know if there is any kind of "official" definition of a
>> high-level language.  But I think a reasonable choice would be to say
>> that a low-level language is one that is defined in terms of the
>> hardware.  Operations in the language do what the hardware says they
>> will do.  A high-level language is one that is defined independently
>> of any particular hardware.
>>
>> By that definition, C is a high-level language - it is defined in
>> terms of an abstract machine.  It has some implementation-dependent
>> factors (as do all languages - though C has perhaps more than most,
>> and is more explicit about it than most).  But those affect particular
>> implementations of the language rather than the language itself.
>>
>> Another way to distinguish low and high level languages is to consider
>> the usage, and suitability of usage, in "low level" or "systems"
>> coding, close to the hardware, as distinct from more abstract coding.
>> Python is then "high level", with native support for infinite
>> precision integers, hash maps, standard libraries for
>> application-level features, etc.  C is "low level" for supporting
>> efficient and direct hardware access and systems coding.  But C++
>> would then be both a low-level /and/ a high-level language.
>>
>> I personally think it is more accurate to say that C is a low-level
>> high-level language, or a high-level language targeting low-level
>> programming.  A binary low/high classification is not particularly
>> useful - it is perhaps better to think of a scale, in which a language
>> like Python would be significantly higher than C.  But as C would
>> score well above 0 here, it is very definitely a high level language.
>
> Well, I can use C to steal bits from a pointer. Pretty nice and useful,
> from time to time, so to speak... :^)

I have a dynamic scripting language where I can do those tricks too.
It's not just the domain of C, or low-level languages!

I would place my two languages (M and Q here, where A=assembly, C=C,
P=Python) on this scale:

A---C-M----Q---------P---------- ...

Way off to the right you'll probably find functional ones like Haskell,
and there are probably even higher level languages too.

I would call A a low-level language, and C and M lower-level HLLs.

Rust might be somewhere between C and P, but the truth is that is it not
a linear scale.

On 18/07/2023 08:55, David Brown wrote:
> On 18/07/2023 04:25, Ben Bacarisse wrote:

>> That's what every compiler ever written does: process a language defined
>> by the author(s), the options used and the bugs in the implementation.
>> I really don't know what you hope to gain by saying obvious things like
>> this other than to (incorrectly) imply that C -- the language -- is not
>> defined by it's defining documents -- the ISO standards -- but by
>> compiler options.
>>
>
> One thing to remember is Bart's comparison here.  He is forever
> comparing C to his own language - a language that is, in a sense,
> constant because there is only one implementation of it.  There are no
> flags that affect the language, because what might be an optional
> feature in another compiler, is for him a fixed change to the language
> implemented by changing the compiler source.  With only one user, and
> only one compiler, there are no options or variations.  It is fully
> portable - all programs in his language can be compiled by all
> implementations.  There are no conflicts between language definition
> documents and implementations, because there are no documents defining
> the language - the language is whatever the implementation does.  There
> is no scope for alternative interpretation of the definition - with one
> user, there is always consensus.  There are no flaws in the language -
> it works exactly as its users want it to.
>
> Because Bart has primarily used his own language (or languages) for many
> decades, he struggles to understand how things work for a language that
> has developed over decades, has formal standards, has countless
> implementations, countless users, and an enormous quantity of code
> written to wildly varying qualities.

That's not true. My language has evolved considerably since the the
first version in the early 80s, far more than C, but not quite as much
as Fortran.

There are have been countless compilers and various machine targets,
some ILs, and even ones generating C32 and C64 (versions of C that must
be compiled with -m32 or -m64).

Actually even now it is volatile, and only recently I decided to keep it
stable.

The actual level of it (see my post before this one) is not much higher
than C, but I have been able to experiment with lots of different ideas
that suit this level of language.

That's why I can be so vocal about C.

I also understand why C development needs to be constrained, yet many
things could be done but aren't, like making compilers default to the
newest, safest standards, and /require/ options to compile legacy code.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> Fun times! Storing meta data in a pointer, then masking it off before we
> actually use the pointer. Undefined behavior for sure, but can it work and
> be used in highly beneficial ways, yup.

This can be done without any undefined behaviour. It's not "portable"
but that's not the same as UB.

--
Ben.

On 2023-07-18, Bart <bc@freeuk.com> wrote:
> On 18/07/2023 03:25, Ben Bacarisse wrote:
> >>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
> >>> -fsanitize=undefined -Wbad-function-cast \
> >>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral
> -Wcast-align \
> >>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
> >>>
> >>> so I can see problems as early as possible.
>
> With your options I managed to still produce an executable for this:
>
> int main() {main(1, 2.0, "three", main, main, main();}

How did you manage to produce an executable for that?
Here, gcc says:

a.c:1:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
int main() {main(1, 2.0, "three", main, main, main();}
^~~~
a.c: In function 'main':
a.c:1:53: error: expected ')' before ';' token
int main() {main(1, 2.0, "three", main, main, main();}
^
a.c:1:54: error: expected ';' before '}' token
int main() {main(1, 2.0, "three", main, main, main();}
^
and no executable is produced.

On 18/07/2023 13:16, Ike Naar wrote:
> On 2023-07-18, Bart <bc@freeuk.com> wrote:
>> On 18/07/2023 03:25, Ben Bacarisse wrote:
>>>>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
>>>>> -fsanitize=undefined -Wbad-function-cast \
>>>>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral
>> -Wcast-align \
>>>>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>>>>>
>>>>> so I can see problems as early as possible.
>>
>> With your options I managed to still produce an executable for this:
>>
>> int main() {main(1, 2.0, "three", main, main, main();}
>
> How did you manage to produce an executable for that?
> Here, gcc says:
>
> a.c:1:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
> int main() {main(1, 2.0, "three", main, main, main();}
> ^~~~
> a.c: In function 'main':
> a.c:1:53: error: expected ')' before ';' token
> int main() {main(1, 2.0, "three", main, main, main();}
> ^
> a.c:1:54: error: expected ';' before '}' token
> int main() {main(1, 2.0, "three", main, main, main();}
> ^
> and no executable is produced.

There's a typo because I typed it by hand. This is the actual program:

#include <stdio.h>

int main() {
main(1,2.0,"three", main, main, main());
}

All those options will still only warn.

On 18/07/2023 05:27, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> (In the case of Fortran, I remember using machine-specific types such
>> as INTEGER*4 (i32) in 1979; was there anything similar in C before
>> C99?
>>
>> Funny that the non-low-level language had machine types, and
>> close-to-the-metal C didn't!
>
> So your complaint is that C has fixed-width types *now*, but didn't
> acquire them until 24 years ago?

I would dispute that it properly 'acquired' them. What happened is that
someone put a bunch of typedefs and macros into a header, and decreed
that that header is now part of C.

Forget to include that header, and those types don't exist. Meanwhile
format codes and literal suffixes still work with 'long' and 'long long'.

So they were crudely bolted on. You see the effects of it in many
libraries and open source apps that still prefer to define their own
versions despite stdint.h, or on top of stdint.h.

Some compilers may indeed build them in the form of special `__int64`
types for example, but are not allowed to expose those because the
language says it must be done via stdint.h.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:
>
>
>> OK. But in that case why is C's so-called portability touted so much?
>
>Who touts it? Picking an old version of C, and sticking to the standard
>can result in reasonably portable programs, but the whole notion is
>fraught with misunderstandings and is not easy to define. C is often
>thought of as being very portable because almost every platform has a C
>compiler, but writing highly portable is very hard and few people know
>how to do it well. Does that mean that C is portable or does it mean it
>isn't? The question is not an easy one to answer.

Indeed, it is almost impossible to write a useful application
in portable C. Yes, you can write simple filters using the
primitive and inefficient stdio functionality, but any application
interested in performance will use operating-specific API's
(POSIX, Windows API), which limits the portability of the
application to implementations of those APIs.

>
>> (In the case of Fortran, I remember using machine-specific types such as
>> INTEGER*4 (i32) in 1979; was there anything similar in C before C99?
>
>For a while in the 1970s and into the 80s I would have said that FORTRAN
>66 was probably the most "portable" language around. It was widely
>implemented and had a strict language standard.

I would have said the same about COBOL 68. But even COBOL generally
had implementation specific options and syntax (Burroughs COBOL68
compiler even had inline assembly capability; called "ENTER SYMBOLIC").

>> BTW I can't remember using any options when compiling Fortran.
>
>Really? Odd. I remember needing multiple JCL cards to invoke the IBM
>360 FORTRAN compiler, but you didn't get much choice about the language.

The Burroughs Fortran compilers had $ (in column 1) directives that
selected a number of compile-time options, including selective
compilation. Likewise the other compilers (COBOL, BPL, et alia).

On 18/07/2023 13:06, Bart wrote:
>
> On 18/07/2023 03:25, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> >> OK. But in that case why is C's so-called portability touted so much?
> >
> > Who touts it?  Picking an old version of C, and sticking to the standard
> > can result in reasonably portable programs, but the whole notion is
> > fraught with misunderstandings and is not easy to define.  C is often
> > thought of as being very portable because almost every platform has a C
> > compiler, but writing highly portable is very hard and few people know
> > how to do it well.  Does that mean that C is portable or does it mean it
> > isn't?  The question is not an easy one to answer.
>
> So why pick on [criticise] a method of accessing the top bit of a 32-bit
> word that is going to work on all platforms of interest?

Perhaps because it is /not/ going to work on "all platforms of interest"
unless your interest is only in limited poorly optimising tools and in
"it seemed to work when I tried it" coding ?

Do you /still/ not understand? The concern is nothing to do with the
size of "int" and "float" - it is the reliance on /undefined/ behaviour.
Even on compilers which can't do type-based alias analysis, the
behaviour is rarely or never documented - it is /undefined/ because no
one has defined it. And for more serious compilers, you will not get
the results you are imagining because your code makes no sense. It
might all seem to work fine in simple cases, and then fail later in more
advanced use-cases - that's why you want a guarantee that it will work,
because the behaviour is defined and documented.

> What's really going on is that because that method might be tagged as UB
> (/because/ of various obscure architectures where it won't work), we're
> not allowed to use it in cases (perhaps the majority) where there would
> be no problem.

/Please/ try to keep up. The meaning of code in a programming language
is not defined by how it /could/ have been described, but how it is
/actually/ described and specified. C /could/ have been defined to
allow such cross-type accesses to work as though it didn't have a type
system. But it was not so defined - it was defined on the assumption
that people access floats as floats and access ints as ints, and when
they need to do something weird and outside the type system, they write
extra code to make that work safely.

>
> > C has changed quite a bit too
>
> C's changes are minor. Fortran changed from being unstructured, to
> structured, among other major differences.
>
>
> >>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
> >>>       -fsanitize=undefined -Wbad-function-cast \
> >>>       -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral
> -Wcast-align \
> >>>       -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
> >>>
> >>> so I can see problems as early as possible.
> >>
> >> So you're using a version of the language defined by those options.
> >
> > That's what every compiler ever written does: process a language defined
> > by the author(s), the options used and the bugs in the implementation.
>
> gcc allows for myriad different dialects, and that's before extensions
> are considered.
>
> My bcc compiler allowed for just two: there was an `-old` switch to
> enable features I didn't want to have, but were necessary to compile
> some existing programs.

Ah, so your compiler is "better" because it is much more limited and
can't handle other people's code?

>
> (One consequence of gcc allowing deprecated features by default is that
> uses of those features are not curtailed; they are perpetuated.)

One of the consequences of having your own personal little compiler is
that no one but you uses it, so in the big picture it is completely
irrelevant. You can put whatever defaults or switches you like, and it
doesn't matter to anyone but you.

One of the consequences of being a major toolchain is that vast numbers
of people use it, and so defaults can't be changed without having big
effects on lots of people and programs.

On 18/07/2023 13:10, Bart wrote:
> On 18/07/2023 05:27, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> (In the case of Fortran, I remember using machine-specific types such
>>> as INTEGER*4 (i32) in 1979; was there anything similar in C before
>>> C99?
>>>
>>> Funny that the non-low-level language had machine types, and
>>> close-to-the-metal C didn't!
>>
>> So your complaint is that C has fixed-width types *now*, but didn't
>> acquire them until 24 years ago?  It's difficult to imagine any
>> explanation that would satisfy you.
>>
>> And you're referring to the intN_t types as "machine types"?
>> Why do you call them that?
>
> OK, so, N has the values of 8, 16, 32, 64, which by some remarkable
> coincidence are also the bit-widths supported by most current hardware,
> but that doesn't make them machine types?
>

No.

This is comp.lang.c, so we talk about C here. While there is no C term
"machine type", the obvious interpretation of the phrase would be
machine-specific types. That means char, short, int, long, long long -
the types whose precise size and characteristics are machine-dependent.

Types like int32_t are machine /independent/ types - they are the
fixed-size integer types.

I think it is absolutely fine to use the fixed-size types for most code
(though arguably something like int_fast32_t is often a better choice).
But I don't think it is appropriate to call them "machine types".

(To be accurate, the existence of, for example, int32_t is
implementation dependent. But I think any system that doesn't support
that one will be either ancient or extremely niche. Some current
processors don't support 8-bit or 16-bit types, but they are also niche.)

On Tuesday, 18 July 2023 at 15:34:56 UTC+1, Scott Lurndal wrote:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> >Bart <b...@freeuk.com> writes:
> >
> >
> >> OK. But in that case why is C's so-called portability touted so much?
> >
> >Who touts it? Picking an old version of C, and sticking to the standard
> >can result in reasonably portable programs, but the whole notion is
> >fraught with misunderstandings and is not easy to define. C is often
> >thought of as being very portable because almost every platform has a C
> >compiler, but writing highly portable is very hard and few people know
> >how to do it well. Does that mean that C is portable or does it mean it
> >isn't? The question is not an easy one to answer.
> Indeed, it is almost impossible to write a useful application
> in portable C. Yes, you can write simple filters using the
> primitive and inefficient stdio functionality, but any application
> interested in performance will use operating-specific API's
> (POSIX, Windows API), which limits the portability of the
> application to implementations of those APIs.
>
The Baby X resource compiler is written in portable C.
It's not. a trivial program.

https://github.com/MalcolmMcLean/babyxrc

wtorek, 18 lipca 2023 o 09:36:11 UTC+2 Chris M. Thomasson napisał(a):
> On 7/18/2023 12:33 AM, Chris M. Thomasson wrote:
> > On 7/18/2023 12:26 AM, David Brown wrote:
> >> On 18/07/2023 00:01, Chris M. Thomasson wrote:
> >>> On 7/17/2023 3:01 PM, fir wrote:
> >>>> poniedziałek, 17 lipca 2023 o 08:22:38 UTC+2 David Brown napisał(a):
> >>>>> C is a high level language.
> >>>>
> >>>> i propose to say c is mid-level language.. i would say its closer to
> >>>> low-lewel than high-level
> >>>
> >>> I tend to agree with that.
> >>>
> >>
> >> I don't know if there is any kind of "official" definition of a
> >> high-level language. But I think a reasonable choice would be to say
> >> that a low-level language is one that is defined in terms of the
> >> hardware. Operations in the language do what the hardware says they
> >> will do. A high-level language is one that is defined independently
> >> of any particular hardware.
> >>
> >> By that definition, C is a high-level language - it is defined in
> >> terms of an abstract machine. It has some implementation-dependent
> >> factors (as do all languages - though C has perhaps more than most,
> >> and is more explicit about it than most). But those affect particular
> >> implementations of the language rather than the language itself.
> >>
> >> Another way to distinguish low and high level languages is to consider
> >> the usage, and suitability of usage, in "low level" or "systems"
> >> coding, close to the hardware, as distinct from more abstract coding.
> >> Python is then "high level", with native support for infinite
> >> precision integers, hash maps, standard libraries for
> >> application-level features, etc. C is "low level" for supporting
> >> efficient and direct hardware access and systems coding. But C++
> >> would then be both a low-level /and/ a high-level language.
> >>
> >> I personally think it is more accurate to say that C is a low-level
> >> high-level language, or a high-level language targeting low-level
> >> programming. A binary low/high classification is not particularly
> >> useful - it is perhaps better to think of a scale, in which a language
> >> like Python would be significantly higher than C. But as C would
> >> score well above 0 here, it is very definitely a high level language.
> >
> > Well, I can use C to steal bits from a pointer. Pretty nice and useful,
> > from time to time, so to speak... :^)
> >
> Fun times! Storing meta data in a pointer, then masking it off before we
> actually use the pointer. Undefined behavior for sure, but can it work
> and be used in highly beneficial ways, yup.

its probably bad idea (at least often)
i made such things when coduing my furia (fury) compiler, it was becouse when im
production mkode i hurry much and do what is easiest and most handy, it seem
to be handy in one place to store something in pointer (i dont remember what
for a moment) but soon i regretted it... more worse reverting it now would need few days of work which gives nothing to production (but it would need be done as its just bad)

it work but the code is not clear, yet i in fact has some runtime errors/segfaults which i normally no experience..but overally i was not experienced in writing compilers and did it hack way

On 18/07/2023 15:36, David Brown wrote:
> On 18/07/2023 13:06, Bart wrote:

>> My bcc compiler allowed for just two: there was an `-old` switch to
>> enable features I didn't want to have, but were necessary to compile
>> some existing programs.
>
> Ah, so your compiler is "better" because it is much more limited and
> can't handle other people's code?

There are some features that need to be enabled, yes. Is that bad? It
means I can't compile and run my nonsense example without explicitly
enabling it.

>
>>
>> (One consequence of gcc allowing deprecated features by default is
>> that uses of those features are not curtailed; they are perpetuated.)
>
> One of the consequences of having your own personal little compiler is
> that no one but you uses it, so in the big picture it is completely
> irrelevant.  You can put whatever defaults or switches you like, and it
> doesn't matter to anyone but you.

What I'm saying makes sense, and you know it, but won't admit it.

> One of the consequences of being a major toolchain is that vast numbers
> of people use it, and so defaults can't be changed without having big
> effects on lots of people and programs.

The defaults can't be changed, ever?

These compiler have version numbers, and I'm sure people using them
seriously will not rely on defaults.

And if it comes down to it, call the newer version gcc2 or something;
it's really not hard.

The problem is the vast number of people using it casually who will keep
using bad coding styles out of habit, or because they are not admomished
by the compiler.

Then there are the compilers that need to be drop-in replacements for
gcc that now need to replicate every misfeature, down to calling default
output files a.out or a.exe.

David Brown <david.brown@hesbynett.no> writes:

> On 18/07/2023 04:25, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 18/07/2023 01:28, Ben Bacarisse wrote:
<cut>
>>>> For example, when someone posts here, I will compile it with something
>>>> like this
>>>>
>>>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
>>>> -fsanitize=undefined -Wbad-function-cast \
>>>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral -Wcast-align \
>>>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>>>>
>>>> so I can see problems as early as possible.
>>>
>>> So you're using a version of the language defined by those options.
>
> Note (this is primarily for Bart - it's nothing new to Ben) that none of
> these flags define the language - they merely ask for warnings on
> suspicious code. "-std=c11" /chooses/ which language standard to use, but
> does not define it.
>
> gcc does offer options that change the language - you can choose to support
> gcc extensions, and you can add additional semantics to C with options such
> as "-fwrapv" and "-fno-strict-aliasing". But those are not in Ben's list.

I may be missing the distinction you are making, but the languages
accepted by gcc -std=c11 and gcc -std=c11 -pedantic are very different!

<cut>
--
Ben.

Bart <bc@freeuk.com> writes:

> On 18/07/2023 03:25, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>> OK. But in that case why is C's so-called portability touted so much?
>>
>> Who touts it? Picking an old version of C, and sticking to the standard
>> can result in reasonably portable programs, but the whole notion is
>> fraught with misunderstandings and is not easy to define. C is often
>> thought of as being very portable because almost every platform has a C
>> compiler, but writing highly portable is very hard and few people know
>> how to do it well. Does that mean that C is portable or does it mean it
>> isn't? The question is not an easy one to answer.
>
> So why pick on [criticise] a method of accessing the top bit of a 32-bit
> word that is going to work on all platforms of interest?

It's getting increasingly hard to believe you don't know. I've
commented before that you and I seem to view programming in entirely
different and incompatible ways, so I suppose it's possible that you
think that some code that worked today is correct (today).

> What's really going on is that because that method might be tagged as UB
> (/because/ of various obscure architectures where it won't work), we're not
> allowed to use it in cases (perhaps the majority) where there would be no
> problem.

It is explicitly stated to be undefined. It's pure spin to say that it
"might be tagged as UB". It's been undefined since ANSI C in 1989.

The /reason/ a construct is undefined has no bearing on my objection to
using it.

You /are/ allowed to use it. The fact that it is undefined simply means
that the definition of the language does not say what the code means.

>> I really don't know what you hope to gain by saying obvious things like
>> this other than to (incorrectly) imply that C -- the language -- is not
>> defined by it's defining documents -- the ISO standards -- but by
>> compiler options.
>
> I've given examples in the past where the same C program either:
>
> * Passed with 0 lines of errors or warnings
>
> * Passed with 28,000 lines of warnings and notes (on a 40Kloc input)

So you are still trying to imply that C -- the language -- is not
defined by it's defining documents -- the ISO standards -- but by
compiler options. You are still wrong.

> I think you're just not seeing it. A compiler should take more
> responsibility for deciding a valid program, or the language should do so
> if it merely leaves things to the implementation.

I have been seeing your stated preferences for years. But what /you/
want from a tool like gcc is not some sacrosanct rule. It's a
preference.

>>>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
>>>> -fsanitize=undefined -Wbad-function-cast \
>>>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral -Wcast-align \
>>>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>>>>
>>>> so I can see problems as early as possible.
<quoted material re-ordered for clarity>

>> Fortunately, gcc is a quality compiler and these options make the
>> language it accepts as close to ISO standard C (the 2011 version) as I
>> can get it, but there will always be bugs and misunderstandings.
>
> With your options I managed to still produce an executable for this:
>
> int main() {main(1, 2.0, "three", main, main, main());}
<typo corrected>

Are you seriously going to go over this old ground again? I can't
believe you've forgotten, so what do think would be the point of
re-hashing it all again?

> My bcc compiler failed it /unless/ I specified '-old'.

Curious. Why is the program acceptable with that flag but not without?

> Without any options, gcc said nothing about it (a quality compiler
> indeed!).

The tool did what you asked. As it happens, I'd prefer different gcc
defaults as well, but there are just too many scripts, makefiles and
build systems out there that would break. But since providing your own
defaults is easy, I don't really mind much. I certainly would not make
a point if posting about it every few years.

--
Ben.

On 2023-07-19, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Bart <bc@freeuk.com> writes:
>> My bcc compiler failed it /unless/ I specified '-old'.
>
> Curious. Why is the program acceptable with that flag but not without?

So that you could have two languages in one, distinguished by
a compiler option.

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

On 19/07/2023 03:29, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 18/07/2023 04:25, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 18/07/2023 01:28, Ben Bacarisse wrote:
> <cut>
>>>>> For example, when someone posts here, I will compile it with something
>>>>> like this
>>>>>
>>>>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
>>>>> -fsanitize=undefined -Wbad-function-cast \
>>>>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral -Wcast-align \
>>>>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>>>>>
>>>>> so I can see problems as early as possible.
>>>>
>>>> So you're using a version of the language defined by those options.
>>
>> Note (this is primarily for Bart - it's nothing new to Ben) that none of
>> these flags define the language - they merely ask for warnings on
>> suspicious code. "-std=c11" /chooses/ which language standard to use, but
>> does not define it.
>>
>> gcc does offer options that change the language - you can choose to support
>> gcc extensions, and you can add additional semantics to C with options such
>> as "-fwrapv" and "-fno-strict-aliasing". But those are not in Ben's list.
>
> I may be missing the distinction you are making, but the languages
> accepted by gcc -std=c11 and gcc -std=c11 -pedantic are very different!
>

I was trying to make a distinction between /defining/ a language variant
and /choosing/ a language variant. The language variant you get with
"gcc -std=c11 -pendantic" is not defined by those flags - it is defined
by the ISO standards.

I would also not describe "-std=c11" and "-std=c11 -pendantic" as "very
different" languages or language variants. The "-pedantic" flag makes
gcc give warnings on certain code constructs that were valid in older C
versions but not in C11, and on constraint errors where the standard
requires a diagnostic even though the compiler can generate reasonable
code. But these are warnings, not errors, and the compiler will in many
cases generate warnings on such code even with no flags. (With no std
flag, it defaults to -std=gnu17 on current gcc versions, IIRC.)

"-pedantic-errors" turns many of these warnings into hard errors, so
that it will not compile - that makes the argument of "different
languages" much stronger.

However, I still feel "different" languages is a poor description - even
if you compare "-std=c11 -pedantic-errors" with "-std=gnu11", you are
talking about extensions or additional features - one language is a
subset of the other. Code that is accepted by the compiler with both
flag settings (whether you consider "accepted" to mean accepted without
errors, or accepted without warnings) has the same semantics.

There /are/ gcc flags that actually make the language different, but you
need to pick them specifically. "-fgnu89-inline", for example, will
make the "inline" keyword work like the pre-standardised version that
gcc supported before C99. "-fsigned-char" or "-funsigned-char" will
change the sign of plain "char" to something other than the
ABI-specified choice for the target, which can affect the semantics of
the code.

And there are flags that add additional semantics to the language, but
since the default for these is UB, the default is still a subset -
things like "-fwrapv" and "-ftrapv", and "-fno-strict-aliasing".

So for your list of flags above, consider "-pedantic-errors" rather than
"-pedantic". (For clang fans, clang treats "-pedantic" as
"-pedantic-errors".)

Personally for testing if code is "standard C", I use:

gcc -O2 -std=c17 -Wall -Wextra -Wpedantic

That gives more warnings than required by the standard, but usually they
are an indication of a problem or questionable code, so they are
generally helpful in the context. I enable optimisation because it
enables more code analysis and therefore more warnings.

On 18/07/2023 18:59, Bart wrote:
> On 18/07/2023 15:36, David Brown wrote:
>> On 18/07/2023 13:06, Bart wrote:
>
>>> My bcc compiler allowed for just two: there was an `-old` switch to
>>> enable features I didn't want to have, but were necessary to compile
>>> some existing programs.
>>
>> Ah, so your compiler is "better" because it is much more limited and
>> can't handle other people's code?
>
> There are some features that need to be enabled, yes. Is that bad? It
> means I can't compile and run my nonsense example without explicitly
> enabling it.
>

I'm fine with a compiler needing a switch to allow outdated and
dangerous code constructs - that's good. (gcc can't do that, for
historical reasons - it's something you have to do before a tool gets
any widespread use.)

But your compiler won't handle a lot of other modern C constructs, and I
don't see how you view that as an advantage. It's fine if you feel your
compiler is good enough for what you need - but not that it is /better/
because of its limitations.

>>
>>>
>>> (One consequence of gcc allowing deprecated features by default is
>>> that uses of those features are not curtailed; they are perpetuated.)
>>
>> One of the consequences of having your own personal little compiler is
>> that no one but you uses it, so in the big picture it is completely
>> irrelevant.  You can put whatever defaults or switches you like, and
>> it doesn't matter to anyone but you.
>
> What I'm saying makes sense, and you know it, but won't admit it.
>
>> One of the consequences of being a major toolchain is that vast
>> numbers of people use it, and so defaults can't be changed without
>> having big effects on lots of people and programs.
>
> The defaults can't be changed, ever?

Almost correct. Defaults can only be changed very carefully, very
slowly. Debates on the gcc mailing lists come up regularly on this
topic, as many people (including me) think it would be far better if gcc
was much stricter by default. The counter-side is that it is very
important that gcc continue to be able to compile code that it has
always compiled - the value of existing code is enormous. Proposals
have included trying to split the compiler into a "systems" compiler
with few warnings and support for old code, and a "developer" compiler
with stricter checking and more developer help and warnings enabled.
(This would just be done by modifying the default flags depending on the
name used to invoke the compiler - not by having different compilers.)

But it is usually pointed out that any reasonably competent developer
already enables lots of warnings and checks, and uses a build system
that supports that easily (whether it be "make", bash aliases, Windows
bat files, and IDE with options dialog, or whatever.) The kind of
developer that can't or won't use tools to help their work probably
won't pay much attention to the warnings anyway.

Some things do change - "-fno-common" is the default for gcc, since gcc
10 (IIRC). Many things that are outdated are warnings (but not errors)
by default.

>
> These compiler have version numbers, and I'm sure people using them
> seriously will not rely on defaults.
>

That depends on the kind of coding you do.

If you are making code that will be released in source form, you very
much want it to work with default versions on the systems you target -
you want to minimise the requirements for the people using the code. If
you are making binaries, however, you will often want tight control of
the toolchain so that you can make reproducible builds. In between
these extremes, you may want to specify details of compiler flags in the
build setups or instructions.

> And if it comes down to it, call the newer version gcc2 or something;
> it's really not hard.
>

Oh, it really /is/ hard. That's why I said you simply don't understand
the situation there.

To give a car analogy (since these are always popular, until taken too
far), you live on a sparsely populated island with single track roads.
You don't care which side of the road you drive on. But you think it
would be better if the country switched to the right side, because then
you could buy cheaper left-side-drive cars. And you can't understand
why the rest of the UK does not agree with you - surely it's not hard to
change sides, and then everyone could have cheaper cars!

(There was one of the former British colonies in Africa which realised
that switching from left-side drive to right-side drive was too big a
change to do all in one day. So they changed for buses and lorries one
day, and for private cars the week after!)

> The problem is the vast number of people using it casually who will keep
> using bad coding styles out of habit, or because they are not admomished
> by the compiler.
>
> Then there are the compilers that need to be drop-in replacements for
> gcc that now need to replicate every misfeature, down to calling default
> output files a.out or a.exe.

On Wednesday, 19 July 2023 at 03:31:43 UTC+1, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 18/07/2023 03:25, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>>
> You /are/ allowed to use it. The fact that it is undefined simply means
> that the definition of the language does not say what the code means.
> >> I really don't know what you hope to gain by saying obvious things like
> >> this other than to (incorrectly) imply that C -- the language -- is not
> >> defined by it's defining documents -- the ISO standards -- but by
> >> compiler options.
> >
> > I've given examples in the past where the same C program either:
> >
> > * Passed with 0 lines of errors or warnings
> >
> > * Passed with 28,000 lines of warnings and notes (on a 40Kloc input)
> So you are still trying to imply that C -- the language -- is not
> defined by it's defining documents -- the ISO standards -- but by
> compiler options. You are still wrong.
>
For someone implementing a compiler, the language is defined by the standards
document. But for someone who is not implementing a compiler, the language
is ultimatelt defined by the behaviour of compilers. Of course if you rely on the
behaviour of the compiler on a construct the standard declares as "undefined
behaviour" then you take the risk that another conforming compiler will behave
differently. But it's not a game changer, because if you rely on defined but obscure
behaviour, you take the risk that a compiler will not be conforming, or that the
standard will be revised.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> For someone implementing a compiler, the language is defined by the standards
> document. But for someone who is not implementing a compiler, the language
> is ultimatelt defined by the behaviour of compilers.

I don't agree completely; I see the situation as more symmetric.
I see the standard as a proposed contract between implementers and
users. Neither side is (usually) obligated to accept the contract,
but both sides can choose to do so, and can expect to be able to rely
on the other side to follow the rules. Implementers can provide
non-standard extensions, and users can write code that depends on
those extensions.

An implementation that doesn't at least provide a mode that conforms
to the standard is going to be unpopular, and a programmer who
doesn't know what's guaranteed by the standard and what's specific
to an implementation will have a hard time if they ever want to
use a different implementation.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 19/07/2023 03:31, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 18/07/2023 03:25, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> OK. But in that case why is C's so-called portability touted so much?
>>>
>>> Who touts it? Picking an old version of C, and sticking to the
standard
>>> can result in reasonably portable programs, but the whole notion is
>>> fraught with misunderstandings and is not easy to define. C is often
>>> thought of as being very portable because almost every platform has a C
>>> compiler, but writing highly portable is very hard and few people know
>>> how to do it well. Does that mean that C is portable or does it
mean it
>>> isn't? The question is not an easy one to answer.
>>
>> So why pick on [criticise] a method of accessing the top bit of a 32-bit
>> word that is going to work on all platforms of interest?
>
> It's getting increasingly hard to believe you don't know. I've
> commented before that you and I seem to view programming in entirely
> different and incompatible ways, so I suppose it's possible that you
> think that some code that worked today is correct (today).
>
>> What's really going on is that because that method might be tagged as UB
>> (/because/ of various obscure architectures where it won't work),
we're not
>> allowed to use it in cases (perhaps the majority) where there would
be no
>> problem.
>
> It is explicitly stated to be undefined. It's pure spin to say that it
> "might be tagged as UB". It's been undefined since ANSI C in 1989.

Tell me again what exactly it is that is undefined. Although whatever it
is, I'm likely to disagree that is should be undefined.

Is it accessing an object declared as f32 via an i32* or u32* pointer?

For example (assume both are 32 bits):

float* p = malloc(sizeof(float));

int* q = (void*)(p);

*q; // is it this?

In this case, space for 4 bytes has been allocated. malloc doesn't know
if that space is for floats, ints, or anything else. I genuinely can't
see the problem.

Maybe floats and ints are stored in different kinds of memory in some
peculiar architecture, so that given `float f; int a;`, `&f; &a` are
radically different pointers? (In that case, how are unions of those
even possible?)

Tell me!

Bear in mind that I've created and implemented systems languages for
decades, and have also implemented a version of C. I'm the position of
being able to ensure that such code is well-defined for /my/
implementations on a specified range of targets.

If a C implementation (not mine) decides to seize on UB to make obvious
code do something non-obvious and against the clear intentions of the
programmer, that is not something I would have sympathy with.

>> I've given examples in the past where the same C program either:
>>
>> * Passed with 0 lines of errors or warnings
>>
>> * Passed with 28,000 lines of warnings and notes (on a 40Kloc input)
>
> So you are still trying to imply that C -- the language -- is not
> defined by it's defining documents -- the ISO standards -- but by
> compiler options. You are still wrong.

So the C standard gives no leeway to a compiler in whether a particular
construct in an input should Pass, be given an Warning, or fail with an
Error?

Because it appears to do exactly that here:

int main(void){int a;L:;};

'gcc prog.c` will pass it. With -Wpedantic etc it will show warnings.
And with -Werror too it will fail it.

So, exactly does ISO say should happen? Is it a valid ISO C program or not?

My bcc compiler's C subset passes on the unused `a` and `L` identifiers,
but will report that extraneous ; as an error. You might not agree with
it, but at least it makes its position clear.

Note that my product is a tool to turn source code into binary; it is
not a linter, and it does not give advice.

> Are you seriously going to go over this old ground again? I can't
> believe you've forgotten, so what do think would be the point of
> re-hashing it all again?

Because it is crazy.
>> My bcc compiler failed it /unless/ I specified '-old'.
>
> Curious. Why is the program acceptable with that flag but not without?

My compiler accepts two variations of C for practical reasons. There's
the version I prefer, and the less safe version that is necessary to
build legacy code without needing extensive changes.

I refer to them as 'C' and 'Old C' ('C' is in quotes because the
language I build is non-conforming in many ways.)

On Wednesday, 19 July 2023 at 11:02:30 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> [...]
> > For someone implementing a compiler, the language is defined by the standards
> > document. But for someone who is not implementing a compiler, the language
> > is ultimatelt defined by the behaviour of compilers.
> I don't agree completely; I see the situation as more symmetric.
> I see the standard as a proposed contract between implementers and
> users. Neither side is (usually) obligated to accept the contract,
> but both sides can choose to do so, and can expect to be able to rely
> on the other side to follow the rules. Implementers can provide
> non-standard extensions, and users can write code that depends on
> those extensions.
>
> An implementation that doesn't at least provide a mode that conforms
> to the standard is going to be unpopular, and a programmer who
> doesn't know what's guaranteed by the standard and what's specific
> to an implementation will have a hard time if they ever want to
> use a different implementation.
>
Well for example the standard doesn't guarantee two's complement
representation (or at least didn't, I think it might have changed). So anyone
who relied on that could have seen their code break. But it so unlikely
that it is hardly worth bothering about.

Then to take the current example, I checked and Ben is right. The use of a union
to type pun is "implementation defined". In C. In C++ it's "undefined". Hence my
confusion. But it's not unlikely that C code will be compiled by a C++ compiler.
Now of course you can say "well a C++ compiler compiles a different language,
so all bets are off", but that's being pedantic rather than useful. The fact is
that a C++ compiler is a C compiler which supports the conservative core subset
of the C language, but not necessarily more esoteric features, and you need to
be aware of that if you undertake to write code snippets which will be generally
useful.

David Brown <david.brown@hesbynett.no> writes:

> On 19/07/2023 03:29, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 18/07/2023 04:25, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 18/07/2023 01:28, Ben Bacarisse wrote:
>> <cut>
>>>>>> For example, when someone posts here, I will compile it with something
>>>>>> like this
>>>>>>
>>>>>> gcc -std=c11 -pedantic -D_ANSI_SOURCE -fno-common \
>>>>>> -fsanitize=undefined -Wbad-function-cast \
>>>>>> -Wstrict-prototypes -Wall -Wextra -Wformat-nonliteral -Wcast-align \
>>>>>> -Winline -Wundef -Wcast-qual -Wshadow -Wconversion -ffloat-store
>>>>>>
>>>>>> so I can see problems as early as possible.
>>>>>
>>>>> So you're using a version of the language defined by those options.
>>>
>>> Note (this is primarily for Bart - it's nothing new to Ben) that none of
>>> these flags define the language - they merely ask for warnings on
>>> suspicious code. "-std=c11" /chooses/ which language standard to use, but
>>> does not define it.
>>>
>>> gcc does offer options that change the language - you can choose to support
>>> gcc extensions, and you can add additional semantics to C with options such
>>> as "-fwrapv" and "-fno-strict-aliasing". But those are not in Ben's list.
>> I may be missing the distinction you are making, but the languages
>> accepted by gcc -std=c11 and gcc -std=c11 -pedantic are very different!
>
> I was trying to make a distinction between /defining/ a language variant
> and /choosing/ a language variant. The language variant you get with "gcc
> -std=c11 -pendantic" is not defined by those flags - it is defined by the
> ISO standards.

I am still missing something. How does any flag define a language or
variant rather than just providing a way to choose it?

> I would also not describe "-std=c11" and "-std=c11 -pendantic" as "very
> different" languages or language variants. The "-pedantic" flag makes gcc
> give warnings on certain code constructs that were valid in older C
> versions but not in C11, and on constraint errors where the standard
> requires a diagnostic even though the compiler can generate reasonable
> code.
<cut>
> However, I still feel "different" languages is a poor description - even if
> you compare "-std=c11 -pedantic-errors" with "-std=gnu11", you are talking
> about extensions or additional features - one language is a subset of the
> other. Code that is accepted by the compiler with both flag settings
> (whether you consider "accepted" to mean accepted without errors, or
> accepted without warnings) has the same semantics.

Yes, I thought the problem was one of using terms differently. My
background includes teaching both the formal theory of languages and
introductory programming. This:

int main(void) { return ({0;}); }

is a syntax error in every published version of the C language, right
back to K&R1. Without -pedantic, gcc does not diagnose the syntax
error. Formally, that's accepting a different language, and from the
practical point of view of teaching C, I'd want a student to see a
diagnostic if they wrote that.

> There /are/ gcc flags that actually make the language different, but you
> need to pick them specifically. "-fgnu89-inline", for example, will make
> the "inline" keyword work like the pre-standardised version that gcc
> supported before C99. "-fsigned-char" or "-funsigned-char" will change the
> sign of plain "char" to something other than the ABI-specified choice for
> the target, which can affect the semantics of the code.

Since all we are doing at this point is explaining our terms, I'll just
point out that, to me, C is a language in which the signedness of plain
char is not specified. "-fsigned-char" or "-funsigned-char" specify the
same language. Over the years I've seen both defaults several times, so
now, when I write char, I mentally check that I really mean that. To
me,

char c;

means "let c be char whose signedness I don't care about". For others,
it probably means "let c be a char with native (ABI-defined)
signedness".

> So for your list of flags above, consider "-pedantic-errors" rather than
> "-pedantic".

Obviously I've considered it, but I don't care about the colour of the
diagnostic, and it's actually handy, when compiling code posted here, to
be able to run the executable after reviewing the warnings.

--
Ben.