David Brown <david.brown@hesbynett.no> writes:
> On 02/09/2023 01:02, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>>> of. Then tell me why most C compilers are still compiling that dialect
>>> by default in 2023.
>> [...]
>> Can you clarify what point you're making with `int fred(void){}`?
>> That's a valid function definition and translation unit in every
>> version
>> of ISO C going back to C90, by which I mean that it does not violate any
>> constraint or syntax rule. (I presume we're not concerned with K&R C,
>> which didn't have void.) It is not a valid *program* for a hosted
>> implementation in any version of C, since it lacks a `main` function.
>> A compiler may reasonably warn about the fact that control reaches
>> the
>> end of a non-void function, but the standard doesn't require a
>> diagnostic. Calling `fred` and not using the result is well defined.
>> Calling `fred` and attempting to use the result has undefined behavior.
>> No diagnostic is required, up to and including C23. (There are
>> historical reasons for this, which I won't go into.)
>
> Also note that it is perfectly fine to have :
>
> int fred(void) { }
>
> int boo(void) {
> int x = fred();
> return x + 1;
> }
>
> There is nothing in this code that is undefined behaviour - it's all
> valid C. There is only a problem - undefined behaviour - if the
> program actually /calls/ "boo".

It's "perfectly fine" only in the sense that it doesn't violate
a constraint or syntax rule and doesn't cause undefined behavior
unless it's called. It's still bad code.

I wouldn't mind if a future edition of the C standard added a
requirement that the } of a non-void function must be unreachable
(with an exception for main()). There are languages that have such
a requirement, and in my limited experience it works pretty well.

The problem is that such a requirement requires the compiler
to perform control flow analysis that's not otherwise required.
Most large modern compilers already do such analysis for optimization
and diagnostic purposes; at most they might have to enable it
at all optimization levels. Small "hobby" compilers might have
to do some extra work -- but such compilers often aren't fully
conforming anyway.

Such a requirement would have been a more substantial burden when
the language was originally being defined, and inertia probably
has a lot to do with why it hasn't been imposed since then.

I think we'd need a rigorous definition of reachability that's not too
difficult to implement. It might require adding unnecessary return
statements in some corner cases, but IMHO that's ok. There's precedent
in other languages that C could steal.

Simply requiring a non-void function to have a return statement
*somewhere* would be far less helpful, and would not be worth the
effort. It would allow such obviously incorrect code as:

int fred(void) {
if (condition) return 42;
}

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> In K&R C, a function that performs some action and doesn't return a
>> value might be written as:
>>
>> do_something(void) {
>> if (already_done) return;
>> do_the_thing();
>> }
>
> Nit: in what I call K&R C it would be
>
> do_something() {
> if (already_done) return;
> do_the_thing();
> }

Quite right, thanks.

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

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> Curiously, I wrote a similar function two days ago. I had a table of
> function pointers and I wanted a "nothing here" value I could store and
> test for. Rather than use a null function pointer, I chose
>
> void *no_op(int) { exit(error("placeholder called")); }

The missing identifier for the parameter is a constraint violation.
See N1570 6.9.1p5. gcc rejects it with "-std=c11 -pedantic-errors":

c.c:5:13: error: ISO C does not support omitting parameter names in function definitions before C2X [-Wpedantic]
5 | void *no_op(int) { exit(error("placeholder called")); }

C23 relaxes this requirement.

(exit() is declared with _Noreturn, so the lack of a return statement
shouldn't be a problem if a future standard added the rule we're
discussing.)

[...]

--
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 02/09/2023 22:42, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 02/09/2023 00:02, Keith Thompson wrote:
>
>>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>>
>> I would have said it's obviously wrong.
>
> Curiously, I wrote a similar function two days ago. I had a table of
> function pointers and I wanted a "nothing here" value I could store and
> test for. Rather than use a null function pointer, I chose
>
> void *no_op(int) { exit(error("placeholder called")); }
>
> so that I'd know if it were accidentally called. It uses /two/ features
> you dislike: unnamed parameters in a function definition, and a body
> with no return statement. But I am happy with this choice. Even with
> as many warning on as I can find (my preference during development) gcc
> does not complain about either, and the code does exactly what I want.

The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will
warn).

I understand the point about the void* result type needing to match a
set of other functions. But how much of an imposition is it to supply a
'return NULL' line at the end?

Then it doesn't matter what precedes it; that exit line could could be
commented out, it can be changed, or it's to be maintained by someone
else. Or maybe one day, you will populate this function, and forget the
return statement.

I will speculate that the vast majority of value-returning functions in
a code-base, need to return an actual value, and not risk returning
garbage or possibly crash while trying to return.

So it seems irresponsible to me to not report an inadvertent missing
return, just for the minor benefit of avoiding a superfluous return in a
very small minority of cases.

> I note from another part of the thread that your bcc would most likely
> reject my program.

The missing parameter name, yes (although in the revamp, I enabled that
experimentally).

The missing return can be enabled with -old.

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

> On Saturday, 2 September 2023 at 01:14:36 UTC+1, Ben Bacarisse wrote:
>> Bart <b...@freeuk.com> writes:
>>
>> > On 01/09/2023 19:07, Ben Bacarisse wrote:
>> >> Bart <b...@freeuk.com> writes:
>> >>
>> >>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>> >>>> Bart <b...@freeuk.com> writes:
>> >>>>
>> >>>>> On 01/09/2023 13:08, Richard Harnden wrote:
>> >>>>>> On 01/09/2023 12:01, Bart wrote:
>> >>>>
>> >>>>>>> We are talking about compilers like gcc where you make up your own rules
>> >>>>>>> as to show strictly you want your program treated:
>> >>>>>>>
>> >>>>>>> gcc prog.c zero warnings, writes .exe
>> >>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe
>> >>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe
>> >>>>
>> >>>> Which would you choose as the one and only behaviour?
>> >> No answer? I'll look at the rest of your post, if you decide to address
>> >> this point...
>> > You want an answer, I'd go with the first, since then the three compilers I
>> > use the most work the same way.
>> >
>> > That's not completely satisfactory,
>> It's totally unacceptable to me and, I suspect, a lot of other people.
>> I usually don't want gcc extensions and I want to be able specify the
>> ISO C standard to use at the very least. But I also want as much help
>> spotting errors as the compiler can give me.
>>
> Generally gcc in default mode gives sensible warnings which either indicate
> actual bugs, or odd programming which should be cleaned up.

I don't find that to be the case.

>> You say, dismissively, that one can "make up ones your rules" with gcc,
>> so I am asking for you to say exactly what you don't want me to be able
>> to ask for in terms of checking and/or its absence. Just how crippled
>> and annoying would I find gcc to be if you were in charge? How much
>> choice will you take away?
>>
> In most software, every option you provide represents a failure rather than
> an enhancement. It's often a symptom of sloppy design - a lot of functions
> need parameterising, and instead of doing the hard work and finding the
> parameters to use, the designer just gives the job to the user. It's often a
> symptom of design by programmers rather than user-interface people.
> Programmers don't mind -gamma-correction=1.1, but it's a nightmare to
> someone who just wants to watch telly.

Interfaces should be designed for the target users. It is a nuisance to
me that most GUI programs are not designed for people like me as the
target user.

Trivial example: the default PDF reader on my system is very capable,
but of course I can't search for a regular expression as that would
confuse the other users. Ditto the web browser.

There was a time when users like me were better catered for. There
were, in some desktop systems, "hidden" options to turn on some or all
of this sort of "advanced stuff", but even this seems to be going out of
fashion.

> I suppose you could argue that a compiler is an exception to the
> general rule that programmers shouldn't design interfaces.

However it is covered by the better rule that interfaces should suit the
target users. You can't satisfy everyone, of course, but people writing
C programs have very different requirements to people watching television.

> But the
> general rule is that options make a program easier to write and harder
> to use.

I suspect that's one of your "general rules" where every suggested
exception would be waved away, so instead I'll ask for your best
example. What is, in your mind, the archetypal program that is easier
to write and harder to use because of the options? That would help me
to understand what point you are making here.

--
Ben.

Bart <bc@freeuk.com> writes:

> On 02/09/2023 01:14, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 01/09/2023 19:07, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>
>>>>>>> On 01/09/2023 13:08, Richard Harnden wrote:
>>>>>>>> On 01/09/2023 12:01, Bart wrote:
>>>>>>
>>>>>>>>> We are talking about compilers like gcc where you make up your own rules
>>>>>>>>> as to show strictly you want your program treated:
>>>>>>>>>
>>>>>>>>>   gcc prog.c              zero warnings, writes .exe
>>>>>>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>>>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>>>>>
>>>>>> Which would you choose as the one and only behaviour?
>>>> No answer? I'll look at the rest of your post, if you decide to address
>>>> this point...
>>
>>> You want an answer, I'd go with the first, since then the three compilers I
>>> use the most work the same way.
>>>
>>> That's not completely satisfactory,
>> It's totally unacceptable to me and, I suspect, a lot of other people.
>> I usually don't want gcc extensions and I want to be able specify the
>> ISO C standard to use at the very least. But I also want as much help
>> spotting errors as the compiler can give me.
>>
>>> since there are aspects of the C language I think are too unsafe, but:
>>>
>>> * Have to be passed because they are legal C
>>>
>>> * Cannot reliably be detected by a compiler
>>>
>>> * Are too extensively used in legacy code to be just outlawed.
>> Yet you want to stop people from having hundreds of helpful diagnostics.
>> I suspect you don't mean what you seem to have said -- that gcc should
>> always behave in it's default mode. But if that is not what you meant
>> to say then you have not answered the question at all.
>> You say, dismissively, that one can "make up ones your rules" with gcc,
>> so I am asking for you to say exactly what you don't want me to be able
>> to ask for in terms of checking and/or its absence. Just how crippled
>> and annoying would I find gcc to be if you were in charge? How much
>> choice will you take away?
>
> It seems you want a tool different from what I have in mind. I want a
> straightforward compiler that defaults to the latest version of a language,
> that does not allow user-specified variations.

Odd. I thought you used gcc's labels as values extension. Maybe you
mean you want gcc to use the latest version of GNU-C, the language not
entirely unlike standard C.

Anyway, it's clear that I would not want the compiler you want.

> But it sounds like the C standard itself gives too much leeway in this
> matter anyway. There is apparently no one C language that says that 'int
> fred(void){}' must be illegal.

No C source code is literally illegal. But to get closer to what you
might mean, that function definition violates no constraint in any
C standard to date.

> It also seems like your programs are't even fully specified by the C code
> you write: as well as dozens of compiler options, pragmas and attributes
> within the code, scripts using Bash, Make and M4 are involved, plus
> whatever further languages and config tools might be dragged in, or piled
> on top.

You are off in some fantasy world.

> This is on top of whatever mini-DSLs might be created with the
> preprocessor. And on top of the variations made possibly by the language's
> loosely defined type system.
>
> As I've said many

many, many, many

> times, this is too chaotic for my taste. It is just far
> too open-ended. And it currently panders far too much to ancient legacy
> code and options in /all/ those languages, scripts and tools.

It must be very surprising to you (and possibly annoying) that a
language you consider to be so very deeply flawed has been so wildly
successful. I used to find it annoying when I was trying to teach
people to write programs using cleaner, higher-level languages[1], but I
never found it totally surprising because I understood something of the
social, economic and technical context in which C operated. I might
have taught concurrent and distributed systems using SR[2], but all the
protocols and systems in my research projects used C.

[1] There was a deep vein of "when do we learn proper programming in C"
in some of the classes.

[2] https://www2.cs.arizona.edu/sr/ (That makes me feel old. SR's
/successor/ is now obsolete.)

--
Ben.

On 03/09/2023 00:08, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

>> It also seems like your programs are't even fully specified by the C code
>> you write: as well as dozens of compiler options, pragmas and attributes
>> within the code, scripts using Bash, Make and M4 are involved, plus
>> whatever further languages and config tools might be dragged in, or piled
>> on top.
>
> You are off in some fantasy world.

You have a short memory.

Take the A68G project we recently discussed. Or Gzip. Try and build a
binary using only .c and .h files, and a C compiler. Try and /get/ the
..c and .h files! (Some will be generated by a script in a language that
isn't C.)

Thiago Adams is using a build system based on using C to provide the
scripting needs. That is good; a project still consists of .c files and
needs a C compiler. No extraneous language is needed.

>> times, this is too chaotic for my taste. It is just far
>> too open-ended. And it currently panders far too much to ancient legacy
>> code and options in /all/ those languages, scripts and tools.
>
> It must be very surprising to you (and possibly annoying) that a
> language you consider to be so very deeply flawed has been so wildly
> successful.

Successful by what measure? By seeing off all the competition; being
given massive dispensation by the OS; by generating a lot of employment
for people writing makefiles; by more people choosing to write free,
open source tools?

My own efforts have been usually directed at specific platforms and
applications so could be more streamlined and tidier with little need to
worry about legacy code.

And yet the end result is a language that can be just as useful and
general purpose as C.

(I could have done with an army of people writing optimising compilers
for diverse platforms, creating contents in the form of libraries, or
even just bindings.)

> I used to find it annoying when I was trying to teach
> people to write programs using cleaner, higher-level languages[1],

I'm not even talking about anything much higher level. 'C-level' is
fine, but even at that level, there is so much more that could have been
done better.

Look at this discussion about 'int fred(void){}', and the technical
reasons why that should be valid in a language.

Anywhere else such a possibility in a language would be immediately
dismissed; no arguments! But in C, every bad feature must be allowed,
with a long list of reasons why. The culture is just wrong.

And of course, as you have done, there will always be someone to whom
the feature is indispensable.

> but I
> never found it totally surprising because I understood something of the
> social, economic and technical context in which C operated.

C mostly passed me by for half of my career, and most of the active part
of it. As did Unix and Linux.

I did alright.

> I might
> have taught concurrent and distributed systems using SR[2], but all the
> protocols and systems in my research projects used C.
>
> [1] There was a deep vein of "when do we learn proper programming in C"
> in some of the classes.

I can see it appealing to the more subversive elements who don't like
the heavy discipline of those higher level languages.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> Curiously, I wrote a similar function two days ago. I had a table of
>> function pointers and I wanted a "nothing here" value I could store and
>> test for. Rather than use a null function pointer, I chose
>>
>> void *no_op(int) { exit(error("placeholder called")); }
>
> The missing identifier for the parameter is a constraint violation.
> See N1570 6.9.1p5. gcc rejects it with "-std=c11 -pedantic-errors":
>
> c.c:5:13: error: ISO C does not support omitting parameter names in function definitions before C2X [-Wpedantic]
> 5 | void *no_op(int) { exit(error("placeholder called")); }
>
> C23 relaxes this requirement.

Yes, and gcc has implemented that with -std=c2x which is what I was
using.

--
Ben.

Bart <bc@freeuk.com> writes:

> On 02/09/2023 22:42, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 02/09/2023 00:02, Keith Thompson wrote:
>>
>>>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>>>
>>> I would have said it's obviously wrong.
>> Curiously, I wrote a similar function two days ago. I had a table of
>> function pointers and I wanted a "nothing here" value I could store and
>> test for. Rather than use a null function pointer, I chose
>> void *no_op(int) { exit(error("placeholder called")); }
>> so that I'd know if it were accidentally called. It uses /two/ features
>> you dislike: unnamed parameters in a function definition, and a body
>> with no return statement. But I am happy with this choice. Even with
>> as many warning on as I can find (my preference during development) gcc
>> does not complain about either, and the code does exactly what I want.
>
> The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will
> warn).

Maybe they will all catch up. I used gcc -std=c2x.

> I understand the point about the void* result type needing to match a set
> of other functions.

No, void * is the actual type I wanted. It was not being used as a
point "to any object". Mind you, the return has nothing to do with the
point of the post.

> But how much of an imposition is it to supply a 'return
> NULL' line at the end?

Not much, but why should I add pointless junk?

> Then it doesn't matter what precedes it; that exit line could could be
> commented out, it can be changed, or it's to be maintained by someone
> else.

And then the function would be incorrect. The exit (with a message
output by the error function) is there for a purpose. If I (or someone
else) were to comment it out (by accident, presumably) I /want/ a
warning from gcc that the function won't return a value. If I follow
your advice, nothing will alert me that I've commented out the key part
of the function.

> Or maybe one day, you will populate this function, and forget the
> return statement.

Of course I won't. It's a "sentinel" used to say "nothing here" with
the added advantage that if it gets called because of some bug, I'll
know about it. As I said, I could have used a null pointer (and I'd
still get to know about a mistaken call because of a "crash"), but my
message will tell me more, sooner.

>> I note from another part of the thread that your bcc would most likely
>> reject my program.
>
> The missing parameter name, yes (although in the revamp, I enabled that
> experimentally).
>
> The missing return can be enabled with -old.

Ironic, since the code is targeted at C23!

--
Ben.

Bart <bc@freeuk.com> writes:

> On 03/09/2023 00:08, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> It also seems like your programs are't even fully specified by the C code
>>> you write: as well as dozens of compiler options, pragmas and attributes
>>> within the code, scripts using Bash, Make and M4 are involved, plus
>>> whatever further languages and config tools might be dragged in, or piled
>>> on top.
>> You are off in some fantasy world.
>
> You have a short memory.
>
> Take the A68G project we recently discussed. Or Gzip. Try and build a
> binary using only .c and .h files, and a C compiler. Try and /get/ the .c
> and .h files! (Some will be generated by a script in a language that isn't
> C.)

I didn't write any of those. What are you on about?

>>> times, this is too chaotic for my taste. It is just far
>>> too open-ended. And it currently panders far too much to ancient legacy
>>> code and options in /all/ those languages, scripts and tools.
>> It must be very surprising to you (and possibly annoying) that a
>> language you consider to be so very deeply flawed has been so wildly
>> successful.
>
> Successful by what measure?

Good question. I meant very widely learned and used. To what extent
that reflect success for the people who have learned and used it, or,
for that matter, the projects it was used on, is another question.

> Look at this discussion about 'int fred(void){}', and the technical reasons
> why that should be valid in a language.

> And of course, as you have done, there will always be someone to whom the
> feature is indispensable.

Spin. I never said that. I simply used it since it fit a very specific
situation at the time.

--
Ben.

On Saturday, 2 September 2023 at 23:28:30 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
> > On Saturday, 2 September 2023 at 01:14:36 UTC+1, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >> > On 01/09/2023 19:07, Ben Bacarisse wrote:
> >> >> Bart <b...@freeuk.com> writes:
> >> >>
> >> >>> On 01/09/2023 14:53, Ben Bacarisse wrote:
> >> >>>> Bart <b...@freeuk.com> writes:
> >> >>>>
> >> >>>>> On 01/09/2023 13:08, Richard Harnden wrote:
> >> >>>>>> On 01/09/2023 12:01, Bart wrote:
> >> >>>>
> >> >>>>>>> We are talking about compilers like gcc where you make up your own rules
> >> >>>>>>> as to show strictly you want your program treated:
> >> >>>>>>>
> >> >>>>>>> gcc prog.c zero warnings, writes .exe
> >> >>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe
> >> >>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe
> >> >>>>
> >> >>>> Which would you choose as the one and only behaviour?
> >> >> No answer? I'll look at the rest of your post, if you decide to address
> >> >> this point...
> >> > You want an answer, I'd go with the first, since then the three compilers I
> >> > use the most work the same way.
> >> >
> >> > That's not completely satisfactory,
> >> It's totally unacceptable to me and, I suspect, a lot of other people.
> >> I usually don't want gcc extensions and I want to be able specify the
> >> ISO C standard to use at the very least. But I also want as much help
> >> spotting errors as the compiler can give me.
> >>
> > Generally gcc in default mode gives sensible warnings which either indicate
> > actual bugs, or odd programming which should be cleaned up.
> I don't find that to be the case.
> >> You say, dismissively, that one can "make up ones your rules" with gcc,
> >> so I am asking for you to say exactly what you don't want me to be able
> >> to ask for in terms of checking and/or its absence. Just how crippled
> >> and annoying would I find gcc to be if you were in charge? How much
> >> choice will you take away?
> >>
> > In most software, every option you provide represents a failure rather than
> > an enhancement. It's often a symptom of sloppy design - a lot of functions
> > need parameterising, and instead of doing the hard work and finding the
> > parameters to use, the designer just gives the job to the user. It's often a
> > symptom of design by programmers rather than user-interface people.
> > Programmers don't mind -gamma-correction=1.1, but it's a nightmare to
> > someone who just wants to watch telly.
>
> Interfaces should be designed for the target users. It is a nuisance to
> me that most GUI programs are not designed for people like me as the
> target user.
>
> Trivial example: the default PDF reader on my system is very capable,
> but of course I can't search for a regular expression as that would
> confuse the other users. Ditto the web browser.
>
Exactly. Regular expressions are too hard to use. Unless you happen to
be a programmer. In fact they're too hard for me to use - I seldom
work with text so I almost never use regular expressions. Where I do
it's a case of looking up the syntax.
>
> There was a time when users like me were better catered for. There
> were, in some desktop systems, "hidden" options to turn on some or all
> of this sort of "advanced stuff", but even this seems to be going out of
> fashion.
>
Because programmers write programs, they often design user interfaces.
However large professional software companies employ ergonomics
experts, taking that job away from the programmers. So as you say,
"advanced" options are often culled. All it takes is for the user to somehow
acidentally set the program into advanced mode, and he can't use it, and
that's an expensive call to technical support.
>
> > I suppose you could argue that a compiler is an exception to the
> > general rule that programmers shouldn't design interfaces.
>
> However it is covered by the better rule that interfaces should suit the
> target users. You can't satisfy everyone, of course, but people writing
> C programs have very different requirements to people watching television.
>
No-one is going to deny that interfaces should suit the target users. But
whilst true, it's not helpful. "Programmers shouldn't design interfaces"
is more controversial (often they do, often there is no choice because unlike
Microsoft, you are to small to have a "usability lab" all products have to
go through) . So that makes it worth saying.
>
> > But the
> > general rule is that options make a program easier to write and harder
> > to use.
>
> I suspect that's one of your "general rules" where every suggested
> exception would be waved away, so instead I'll ask for your best
> example. What is, in your mind, the archetypal program that is easier
> to write and harder to use because of the options? That would help me
> to understand what point you are making here.
>
OK, let's take optimisation.
If I were specifying a compiler, I'd say, "I want optimisation to be so fast
that there is no noticeable diference between the speed of optimised and
non-optimised builds. And I want stack trace information to be attached to
the optimised build with no noticeable impact on the speed of execution,
and for that information to be encrypted so that it doesn't assist reverse
engineering".
Now what's going to happen? Probably my engineers are going to say that
this can't be achieved. Maybe by limiting the users to a conservative subset
of C they can give the optimiser an easier job. But the optimisation problem
incorporates the halting problem, there will always be some aggressive
optimisations that take a long time. And stack trace information - unfortunately
programmer tend to put trivial function calls in the inner loop.
So I can maybe have some of what I'm asking for, but not fully, and I'll have to
compromise on some of the other goals, like supporting fancy language
constructs.
So, reluctantly, I agree that I can't have what I want. So we'll need an option.
Debug mode and release mode, maybe more.

But the point is that the option represents a failure to achieve what we want.
For sound technical reasons, but still a falure. The ideal compiler wouldn't
need an option.
And in fact the option is going to cause trouble. Because release mode is
different to debug mode, you're going to get the occasional bug which manifests
itself in release mode but not debug mode. And that bug will tend to be caught late
and be difficult to track down. There's also the posibility that people willl accidentally
ship executables compiled in "debug" mode.
The compiler is a worse compiler because we've been forced to add the options,
They represent failure, not enhancements.

On 2023-09-02, Bart <bc@freeuk.com> wrote:
> On 02/09/2023 17:19, David Brown wrote:
>> On 02/09/2023 12:57, Bart wrote:
>
>>> However, my example is simple: there are clearly zero return
>>> statements; at least one is needed for a value-returning function.
>>
>> By that definition, this version would be perfectly acceptable to you :
>>
>> int fred(void) {
>>     if (1 + 1 != 2) return 0;
>> }
>
> I explained elsewhere that such a simple rule would catch at least some
> errors. And actually, that program is not acceptable to my compiler:

Why would you have this simple rule, when GCC has a decent
implementation of the diagnostic? The only problem is that it's not in
the ISO standard.

Your rule is poor, at times requiring unreachable return statements
to appear, uglyfying code --- and also is not in any ISO standard.

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

On 2023-09-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Bart <bc@freeuk.com> writes:
>> The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will
>> warn).
>
> Maybe they will all catch up. I used gcc -std=c2x.

Which is what "gcc" alone would be if it followed Bart's recommendation
that a compiler should use the current language by default.

People would write code with missing function parameter names and it
would work fine, until they tried to port it.

On 2023-09-03, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Because programmers write programs, they often design user interfaces.
> However large professional software companies employ ergonomics
> experts, taking that job away from the programmers.

That used to make for better user interfaces and experiences. Nowadays,
you would get a better UX if you let the programmers at it. But that
would be bad.

The purpose of bringing in professionals is deliberate degradation
of the user experience in order to optimize for extracting value from
the user.

There is a word for this now: "enshittification".

If the app is free (the market rate for most apps), then a good
experience in that app that doesn't bring you $$$ isn't worth a
damn to the app's vendor.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[...]

> I wouldn't mind if a future edition of the C standard added a
> requirement that the } of a non-void function must be unreachable
> (with an exception for main()). There are languages that have such
> a requirement, and in my limited experience it works pretty well.
>
> The problem is that such a requirement requires the compiler
> to perform control flow analysis that's not otherwise required.
> [...]

The problem is that in C such a determination cannot be made
precisely, for reasons that are both theoretical and practical.
Only heuristics are possible, but requirements in the C standard
are never stated in terms of heuristics (and rightly so).

On 03/09/2023 02:28, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 02/09/2023 22:42, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:

>> I understand the point about the void* result type needing to match a set
>> of other functions.
>
> No, void * is the actual type I wanted. It was not being used as a
> point "to any object". Mind you, the return has nothing to do with the
> point of the post.

Then I /don't/ understand. Why not just make it a 'void' function?

I had assumed the address of no_op was used in a table of function
pointers sharing a void* return type.

>> But how much of an imposition is it to supply a 'return
>> NULL' line at the end?
>
> Not much, but why should I add pointless junk?

And yet, some people are happy to add attributes like _Noreturn. Some
are also happy to write 'i' three times in a simple for-header.

/You/ are even happy to write a return type that doesn't correspond to
the function body.

>> Then it doesn't matter what precedes it; that exit line could could be
>> commented out, it can be changed, or it's to be maintained by someone
>> else.
>
> And then the function would be incorrect. The exit (with a message
> output by the error function) is there for a purpose. If I (or someone
> else) were to comment it out (by accident, presumably) I /want/ a
> warning from gcc that the function won't return a value.

This is what I've complained that it doesn't do.

> If I follow
> your advice, nothing will alert me that I've commented out the key part
> of the function.

I can't win this can I? Obviously if you comment out swathes of code,
the behaviour will change.

But in this case, that is not the issue, as it will silently invoke
undefined behaviour.

This affects the integrity of the underlying code. For most targets, the
likelihood is that a garbage value is returned. That is undesirable.

On Sunday, 3 September 2023 at 08:15:28 UTC+1, Kaz Kylheku wrote:
> On 2023-09-03, Malcolm McLean <malcolm.ar...@gmail.com> wrote:
> > Because programmers write programs, they often design user interfaces.
> > However large professional software companies employ ergonomics
> > experts, taking that job away from the programmers.
> That used to make for better user interfaces and experiences. Nowadays,
> you would get a better UX if you let the programmers at it. But that
> would be bad.
>
> The purpose of bringing in professionals is deliberate degradation
> of the user experience in order to optimize for extracting value from
> the user.
>
> There is a word for this now: "enshittification".
>
> If the app is free (the market rate for most apps), then a good
> experience in that app that doesn't bring you $$$ isn't worth a
> damn to the app's vendor.
>
Markets do sometimes throw up perverse incentives.
But that's not why professional ergonmoics experts are employed, at
least primarily.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> [...]
>
>> I wouldn't mind if a future edition of the C standard added a
>> requirement that the } of a non-void function must be unreachable
>> (with an exception for main()). There are languages that have such
>> a requirement, and in my limited experience it works pretty well.
>>
>> The problem is that such a requirement requires the compiler
>> to perform control flow analysis that's not otherwise required.
>> [...]
>
> The problem is that in C such a determination cannot be made
> precisely, for reasons that are both theoretical and practical.
> Only heuristics are possible, but requirements in the C standard
> are never stated in terms of heuristics (and rightly so).

Yes, I addressed that in my previous post:

I think we'd need a rigorous definition of reachability that's not too
difficult to implement. It might require adding unnecessary return
statements in some corner cases, but IMHO that's ok. There's precedent
in other languages that C could steal.

For example, the closing } in this function:

int func(void) {
if (rand() >= 0)
return 42;
}

will never be reached (because rand() always returns a non-negative
result), but compilers should not be required to do that level of
analysis. In a future version of C that requires the closing } of a
non-void function other than main() to be unreachable, I'd expect this
to be diagnosted as a constraint violation, fixable by adding a return
statement in an else clause or after the if statement.

To put it another way, if the compiler can't prove that the closing }
cannot be reached via any control path *without* making any assumptions
about the values of any conditions, a diagnostic would be required.

I've seen this kind of requirement in other languages, but I don't
remember which ones off the top of my head.

--
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 01/09/2023 23:19, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:

>> And yet, it is possible to create a compiler that gives the common-sense
>> results that one would expect.
>
> That no one's actual production code base would expect, but go on.

And the reason for that is...?

I would speculate that because anything goes, THAT's why there are so
many diverse code bases.

Take this program:

void fred(void){}; void bill(void)

There's an extraneous ";" that the grammar says shouldn't be there, so
it's a syntax error.

Should a compiler fail it or not? I decided mine should. That's quite
petty, but then the fix is trivial. And it means that issue will never
come up again with other compilers.

Most compilers say nothing, or at best can be coaxed into a warning.

But why be so wishy-washy? Other make it legal, or report an error.

What will probably happen is that C27x makes it legal. So all those
compilers being over-lax, suddenly start doing the right thing.

It's almost like the C standard being defined by poor common practice in
compilers. That is not the way to define a language.

>> Yet, not one of those compilers other than bcc stops you creating an
>> executable containing a call to that function.
>
> ISO C doesn't require implementations to fail to translate a program,
> even if it contains syntax errors and constraint violations that a
> conforming implementation must diagnose.

Why not? Is possible that reason for that, is that so many
implementations would not fail such code? So adding that requirement
means those would no longer conform.

Effectively it is condoning poor practice.

>> That can be serious, especially if the return type was a pointer.
>>
>> This is just incredible. You can spout all the nonsense you like about
>> the long history of C, but there is no excuse for a compiler in 2023 to
>> pass code like that with default behaviour.
>
> There is no excuse for a software engineer to be using a compiler
> with default behavior. Not in 2023 or 1993.

OK. So you tell me how a software engineer SHOULD invoke that compiler then.

Then tell me why the compiler doesn't the compiler doesn't just do that
ANYWAY?

Because at this point, 0% of software engineers will be using those
default options. So 100% of them will be typing in the exact same reams
of options for no good reason.

>> You have to give gcc -Wall to even get it to warn.
>
> So why dontcha?
>
> Wait, check this out. I can out-complain you!
>
> You have to give gc **another c** before it even accepts C programs. That's
> how much of a mess it is!

You'll have to explain what gc is.

>> (BTW, which option do you need to force a hard error on that program,
>> which doesn't also fail on unused lables?)
>
> $ gcc -Wall falloff.c -c
> falloff.c: In function ‘func’:
> falloff.c:1:18: warning: label ‘label’ defined but not used [-Wunused-label]
> int func(void) { label: ; }
> ^~~~~
> falloff.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
> int func(void) { label: ; }
> ^~~
>
> Okay, GCC's friendly diagnosis is telling me that the first warning
> is the result of -Wunused-label. Thus:
>
> $ gcc -Wall -Wno-unused-label falloff.c -c
> falloff.c: In function ‘func’:
> falloff.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
> int func(void) { label: ; }
> ^~~
>
> Full disclosure: I'm an idiot too, but I have a nephew here who is
> starting grade 5 next week who helped me with this!
>
> By the way, in human-written code, you probably want to remove
> unused labels.

If they really will be unused. Not just temporarily so during this one
compilation of 100s of versions of the source code.

> In generated code, get all your diagnostics from your own front-end,
> and operate the C compiler quietly.
>
>> I would say, WHY doesn't it do its job anyway? WHY doesn't it operate in
>> a safer mode by default?
>>
>> I can get my bcc to pass that program, but I have to specify -old, and
>> that is only so that existing can be compiled.
>
> -old? What a mess, it's like you have multiple languages in one.
>
> Which one is the real one?

The one accepted without using -old. But it is also my subset of the
language.

I thought mine was poorly defined as there is no standard or spec; I
think it is still better defined than C!

On 02/09/2023 20:53, Bart wrote:
> On 02/09/2023 17:19, David Brown wrote:
>> On 02/09/2023 12:57, Bart wrote:
>
>>> However, my example is simple: there are clearly zero return
>>> statements; at least one is needed for a value-returning function.
>>
>> By that definition, this version would be perfectly acceptable to you :
>>
>> int fred(void) {
>>      if (1 + 1 != 2) return 0;
>> }
>
> I explained elsewhere that such a simple rule would catch at least some
> errors. And actually, that program is not acceptable to my compiler:
>
>     c:\c>type d.c
>     int fred(void) {
>         if (1 + 1 != 2) return 0;
>     }
>
>     c:\c>bcc -c d.c
>     Compiling d.c to d.obj
>     In function fred On line 2 in file d.c
>     ** Code Gen Error: Function needs explicit return statement: fred **
>
>     c:\c>bcc -c d.c -old
>     Compiling d.c to d.obj

So it turns out that simple rules are not sufficient after all.

>
> It suppresses that check when -old is used, to allow existing programs
> to be compiled.

I think that's a good idea. My personal preference would be for gcc to
be far stricter by default (at least roughly equivalent to "gcc -Wall
-O2"). I know that is not going to happen, and I understand why it is
not going to happen, but I still think it's a shame.

(I did file a bug that lead to "-fno-common" being the default, so
there's some progress.)

>
>
>> You'd be surprised how often reality is vastly more complicated than
>
> Exactly. Some of us are trying to make it less complicated.

You can only make it less complicated by limiting the scope - such as
having a small language that is only ever implemented and used by one
person. Then it's a lot easier to keep things small and simple. It
does not scale, however.

> And along
> the way, end up writing safer, less buggy code too!
>

We have absolutely no evidence for that whatsoever. If you had learned
C decades ago, and wrote code C rather than your own personal little
languages, there is no reason to believe you would not have written safe
and bug-free C code. There is nothing inherently unsafe about C coding
- lots of us write safe C code with minimal risk of bugs. C does have
significant scope for writing bad code too, but that does not mean you
can't write good code in the language.

> What exactly are the consequences of requiring programs to satisfy my
> compiler regarding 'return'? Virtually one. But it would then be
> impossible to write a function without a proper return value.
>

You live in such a small bubble! Don't you ever feel the need to look
outside, or at least /think/ a bit about the rest of the world?

Even such a seemingly trivial and obvious change would be an enormous
cost and effort. Making changes to internation standards is a long
process. Changing the thousands of C compilers to support it is a
massive effort. Checking the millions of existing C programs with their
billions of lines of code is even more.

In comparison, having warnings on mainstream compilers that check this
is peanuts (most decent compilers have done so forever). Developers who
know how to do good software development, learn and understand how to
use available tools to the best effect - such as enabling appropriate
warnings and other flags. Developers who don't understand good
engineering practice will make a mess of things anyway.

I agree with you that C would be better if it had been stricter - and
modern languages tend to be much better in such areas. But you are
wrong to think C could easily be changed here.

On 03/09/2023 03:28, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 02/09/2023 22:42, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 02/09/2023 00:02, Keith Thompson wrote:
>>>
>>>>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>>>>
>>>> I would have said it's obviously wrong.
>>> Curiously, I wrote a similar function two days ago. I had a table of
>>> function pointers and I wanted a "nothing here" value I could store and
>>> test for. Rather than use a null function pointer, I chose
>>> void *no_op(int) { exit(error("placeholder called")); }
>>> so that I'd know if it were accidentally called. It uses /two/ features
>>> you dislike: unnamed parameters in a function definition, and a body
>>> with no return statement. But I am happy with this choice. Even with
>>> as many warning on as I can find (my preference during development) gcc
>>> does not complain about either, and the code does exactly what I want.
>>
>> The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will
>> warn).
>
> Maybe they will all catch up. I used gcc -std=c2x.
>
>> I understand the point about the void* result type needing to match a set
>> of other functions.
>
> No, void * is the actual type I wanted. It was not being used as a
> point "to any object". Mind you, the return has nothing to do with the
> point of the post.
>
>> But how much of an imposition is it to supply a 'return
>> NULL' line at the end?
>
> Not much, but why should I add pointless junk?

It would be far worse than pointless. It would hide possible problems
that would otherwise be spotted by the compiler, such as changes to the
function. Maybe you one day would change from using "exit" to using
some other logging or messaging function - you would want a warning from
gcc if that function was not "_Noreturn", and you would not want the
warning hidden by an extra "return NULL;".

Perhaps more importantly, it is never a good thing to have code lines
that are not executed. This could easily confuse people reading the
code - they would be left wondering if the "exit" function returned, so
that the next line would be executed. On some compilers with some
options, it could also lead to warnings about unreachable code. And for
some kinds of programming, you want to do code coverage to ensure that
every line of code is tested - that is impossible with code lines that
cannot be reached.

If I had to add a line here to quieten a compiler warning (perhaps I
knew that "exit" never returns, but the compiler did not know that, if
it were a function declared without _Noreturn or
__attribute__(("noreturn")) ), I would much prefer to write
"__builtin_unreachable();" and a comment.

>
>> Then it doesn't matter what precedes it; that exit line could could be
>> commented out, it can be changed, or it's to be maintained by someone
>> else.
>
> And then the function would be incorrect. The exit (with a message
> output by the error function) is there for a purpose. If I (or someone
> else) were to comment it out (by accident, presumably) I /want/ a
> warning from gcc that the function won't return a value. If I follow
> your advice, nothing will alert me that I've commented out the key part
> of the function.
>
>> Or maybe one day, you will populate this function, and forget the
>> return statement.
>
> Of course I won't. It's a "sentinel" used to say "nothing here" with
> the added advantage that if it gets called because of some bug, I'll
> know about it. As I said, I could have used a null pointer (and I'd
> still get to know about a mistaken call because of a "crash"), but my
> message will tell me more, sooner.
>

And of course if you /did/ change the function to do something else,
/and/ you forgot an appropriate return statement, you would rather have
a warning message than have the message covered up by a
counter-productive fake "return NULL;" line.

>>> I note from another part of the thread that your bcc would most likely
>>> reject my program.
>>
>> The missing parameter name, yes (although in the revamp, I enabled that
>> experimentally).
>>
>> The missing return can be enabled with -old.
>
> Ironic, since the code is targeted at C23!
>

On 03/09/2023 12:02, Bart wrote:
> On 03/09/2023 02:28, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 02/09/2023 22:42, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>
>>> I understand the point about the void* result type needing to match a
>>> set
>>> of other functions.
>>
>> No, void * is the actual type I wanted.  It was not being used as a
>> point "to any object".  Mind you, the return has nothing to do with the
>> point of the post.
>
> Then I /don't/ understand. Why not just make it a 'void' function?
>

It is in a table of function pointers. Presumably some or all of the
other functions in the table return something useful.

> I had assumed the address of no_op was used in a table of function
> pointers sharing a void* return type.

Yes.

While it is possible to use casts between different function pointer
types so that the function pointers in the table point to actual
functions with different types, it is rarely a good idea. You would
have to cast back to the correct type before calling the function. You
are not allowed to call a function that has a type returning void using
a function pointer of a type returning void* .

>
>
>>> But how much of an imposition is it to supply a 'return
>>> NULL' line at the end?
>>
>> Not much, but why should I add pointless junk?
>
> And yet, some people are happy to add attributes like _Noreturn.

Should people be happy to add information that helps the programmer,
helps people reading the code, lets the compiler optimise better, and
lets the compiler and other tools do better automatic checking? Yes,
absolutely - that is /far/ from pointless.

> Some
> are also happy to write 'i' three times in a simple for-header.
>
> /You/ are even happy to write a return type that doesn't correspond to
> the function body.

It corresponds to the required function type (assuming I understand
Ben's code correctly).

>
>>> Then it doesn't matter what precedes it; that exit line could could be
>>> commented out, it can be changed, or it's to be maintained by someone
>>> else.
>>
>> And then the function would be incorrect.  The exit (with a message
>> output by the error function) is there for a purpose.  If I (or someone
>> else) were to comment it out (by accident, presumably) I /want/ a
>> warning from gcc that the function won't return a value.
>
> This is what I've complained that it doesn't do.

It does.

Oh, are you still failing to use gcc correctly, and still complaining
about that?

>
>> If I follow
>> your advice, nothing will alert me that I've commented out the key part
>> of the function.
>
> I can't win this can I?

You could try dropping your paranoia and your mindless hatred of C and
gcc. Then you might "win".

> Obviously if you comment out swathes of code,
> the behaviour will change.
>
> But in this case, that is not the issue, as it will silently invoke
> undefined behaviour.

How would undefined behaviour be invoked here? Since "exit" does not
return, there is no possibility of the calling function attempted to use
the non-existent return value, and thus no undefined behaviour.

>
> This affects the integrity of the underlying code. For most targets, the
> likelihood is that a garbage value is returned. That is undesirable.
>

The likelihood of that is zero - since the function does not return.

Bart <bc@freeuk.com> writes:

> Take this program:
>
> void fred(void){}; void bill(void)

This program has two syntax errors. The one you are talking about and
the missing ; or missing compound statement as the end of the line.

> There's an extraneous ";" that the grammar says shouldn't be there, so it's
> a syntax error.
>
> Should a compiler fail it or not?

The standard says that it should be reported.

> Most compilers say nothing, or at best can be coaxed into a warning.

More rhetorical spin. For gcc and clang (to take tho I can easily test)
if you ask them to check for standard C syntax, they both tell you the ;
should not be there. Both, by default, implement a whole bunch of
extensions. It's not "coaxing" to tell a tool to do what you want.

--
Ben.

On 02/09/2023 23:08, Bart wrote:
> On 02/09/2023 17:11, David Brown wrote:
>> On 02/09/2023 01:02, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>> [...]
>>>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>>>> of. Then tell me why most C compilers are still compiling that dialect
>>>> by default in 2023.
>>> [...]
>>>
>>> Can you clarify what point you're making with `int fred(void){}`?
>>>
>>> That's a valid function definition and translation unit in every version
>>> of ISO C going back to C90, by which I mean that it does not violate any
>>> constraint or syntax rule.  (I presume we're not concerned with K&R C,
>>> which didn't have void.)  It is not a valid *program* for a hosted
>>> implementation in any version of C, since it lacks a `main` function.
>>>
>>> A compiler may reasonably warn about the fact that control reaches the
>>> end of a non-void function, but the standard doesn't require a
>>> diagnostic.  Calling `fred` and not using the result is well defined.
>>> Calling `fred` and attempting to use the result has undefined behavior.
>>> No diagnostic is required, up to and including C23.  (There are
>>> historical reasons for this, which I won't go into.)
>>
>> Also note that it is perfectly fine to have :
>>
>> int fred(void) { }
>>
>> int boo(void) {
>>      int x = fred();
>>      return x + 1;
>> }
>>
>> There is nothing in this code that is undefined behaviour - it's all
>> valid C.  There is only a problem - undefined behaviour - if the
>> program actually /calls/ "boo".
>
> That sounds like a let-out clause for ALL undefined behaviour in a
> program.

Yes.

There are some things that are undefined behaviour at compile-time, some
things that are UB at link time. But most UB is only UB at run time.
If the problematic code is not run, there is no problem - no UB.

Now, I am all in favour of having compilers warn about such /potential/
UB whenever possible. I use a wide selection of warnings when
compiling, and want my compilers to complain about such code. (I
usually have such warnings marked as errors to make them impossible to
miss.)

But whatever my personal preferences here in terms of using tools to
help me write correct code and avoid mistakes, the fact remains that you
cannot have run-time undefined behaviour in code that is not run.

> So you can have 100,000 lines of code each of which invokes UB
> if executed. but the main program is:
>
>    int main(void) {
>    //  f();              // f is where things get rolling.
>    }
>
> Or maybe you don't a main function at all, as those 100,000 lines form a
> library with no entry point of its own.
>
> In fact, your own fred() function is exported so that could also be called.
>
> So I'm not sure what point you're trying to make.
>
> I can also say that it is fine for my compiler to generate buggy code,
> provided you don't try and execute it!

It /is/ fine to have buggy code that is not run - there will be no
run-time errors and no run-time undefined behaviour.

But it is probably useless code, and being informed about it by your
tools is a good thing.

I think you are mixing up /correctness/ with /usefulness/. It is
/correct/ for a compiler to transform :

unsigned int mult(unsigned int x, unsigned int y) {
return x * y;
}

into

unsigned int mult(unsigned int x, unsigned int y) {
unsigned int z = 0;
for (unsigned int i = 0; i < y; i++) {
z += x;
}
return z;
}
But it is not /useful/ for it to do so.

It is /correct/ for compilers to accept the "fred" and "boo" above.
Indeed, it is /required/ for them to do so for C standard conformance
(though they can complain loudly and give warnings). It is, IMHO, more
useful if they complain and give warning messages. I'd be even happier
for a compiler to make it a hard error - but that would be against the C
standards. So the sensible way for a general-purpose C compiler to
behave is to accept the code and to have options to let those who want
useful checks, have those checks. I'd rather that gcc gave a warning by
default, regardless of the options, but I'm fine with it needing
"-Wall". After all, pretty much no one who is competent as a software
developer would be programming without basic warnings enabled in their
tools somewhere.

>
>> This is the kind of thing that makes warnings and static error
>> checking a challenge in C - in most cases, undefined behaviour is a
>> run-time issue, not a compile-time issue, and the compiler does not
>> know how the program will be run.
>
>
> Well, quite. That's why you diagnose it anyway, since the assumption is
> that that code could well be run at some point, otherwise what was the
> purpose of it?
>

Yes, such warnings are definitely useful. That's why I always enable them.

>>>
>>> Note carefully that I am describing the requirements given by the C
>>> standard, not expressing an opinion on whether they're good or bad.
>
> (Why not express an opinion? Afraid you might agree with me?)
>

I am certainly not afraid to agree with you - I have agreed with you
countless times about things that I would have preferred to be otherwise
in C. (I have also disagreed with you countless times.) But you are
unable to comprehend the difference between someone understanding how C
or gcc works, or why C or gcc works in a particular way, with someone
/wanting/ them to work in that way.

So to be clear - C (the language defined by the standards) regards
"fred" and "boo" as valid code. gcc, by default, regards it as valid
code. gcc, used as a development tool, complains about it. gcc, as I
use it for development, makes it a hard error.

I understand exactly why it is allowed in C. I understand exactly why
it is allowed in gcc. I understand why it would be impossible to change
the rules in C. I understand why it would be very difficult to change
the default behaviour in gcc here.

I would have been happier if C did not allow such code. I would have
been happier if gcc gave at least a warning, and perhaps an error
message, by default - and required specific flags to enabled such code
to be accepted.

Now, does that make you happy?

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Bart <bc@freeuk.com> writes:
>>> The missing parameter makes it fail on tcc, MSVC, bcc and icc (icx will
>>> warn).
>>
>> Maybe they will all catch up. I used gcc -std=c2x.
>
> Which is what "gcc" alone would be if it followed Bart's recommendation
> that a compiler should use the current language by default.

Apart from some debate about what constitutes the "current language".
Does something not yet fully implemented (or even not yet published)
count?

> People would write code with missing function parameter names and it
> would work fine, until they tried to port it.

But that's pretty much always true if you call a C compiler with no
options. It would not matter if gcc followed Bart's recommendation or
if it did what it does now -- code accepted by a naked gcc command is
not going to be portable.

--
Ben.