On 2023-09-01, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-09-01, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> By default, the object file name for a source file is made by
>>> replacing the suffix .c, .i, .s, etc., with .o.
>>
>> I agree that's potentially misleading. I think the intent was that
>> "object file name" is intended to refer just to the file *name*, not the
>> full file *path*.
>
> Ah, but I have a piece of trivia for you:
>
> _GNU Coding Standards_, July 1, 2021:
>
> Please do not use the term “pathname” that is used in Unix
> documentation; use “file name” (two words) instead. We use the term
> “path” only for search paths, which are lists of directory names.
>
> GNU programs and documentation are supposed to use file name
> to refer to a path with multiple components too, not just one
> component.

In the same document, something closer to this overall debate:

The GNU Project regards standards published by other organizations as
suggestions, not orders. We consider those standards, but we do not
“obey” them. In developing a GNU program, you should implement an
outside standard’s specifications when that makes the GNU system better
overall in an objective sense. When it doesn’t, you shouldn’t.

In most cases, following published standards is convenient for users—it
means that their programs or scripts will work more portably. For
instance, GCC implements nearly all the features of Standard C as
specified by that standard. C program developers would be unhappy if it
did not. And GNU utilities mostly follow specifications of POSIX.2;
shell script writers and users would be unhappy if our programs were
incompatible.

But we do not follow either of these specifications rigidly, and there
are specific points on which we decided not to follow them, so as to
make the GNU system better for users.

For instance, Standard C says that nearly all extensions to C are
prohibited. How silly! GCC implements many extensions, some of which
were later adopted as part of the standard. If you want these constructs
to give an error message as “required” by the standard, you must specify
‘--pedantic’, which was implemented only so that we can say “GCC is a
100% implementation of the standard”, not because there is any reason to
actually use it.

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

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.

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.

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.

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

Funny how discussions here often focus on some exact wording in the C
standard, while the rest of it leaves gaping holes in the spec large
enough to drive a bus through.

(I've working on a new systems language where instead of there being
exactly one, fixed language that needs nothing else to build projects,
there will a closely integrated, embedded scripting language.

I thought having two languages in one would be too outre, but it is
nothing on C, or rather that vague, sprawling mess of languages,
dialects and tools that I've described.)

Anyway, I think I've given you an idea of where I stand.

On 02/09/2023 02:12, Kaz Kylheku wrote:
> On 2023-09-02, Bart <bc@freeuk.com> wrote:
>> 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.
>>
>> But in this group, so many people have argued that black is white, or
>> vice versa, that nothing surprises me any more.
>
> It's a good idea to produce a diagnostic in cases when it's obvious
> that the control graph of the function reaches the end without
> hitting a return statement.
>
> C allowing the return, provided that the caller doesn't use the
> value, is a bit of a relic. Early C worked that way because
> every function returned int, but not every function needed
> to return anything. It's not a good feature today.
>
> Keith seems to have mentioned that something had been done about it
> in C23?
>
> Anyway, compilers can diagnose it even though it's not required.
>
> It would be significantly more difficult to work with C without
> compilers that go beyond required diagnostics.
>
> You can't just blindly diagnose this as a syntactic issue; i.e.
> that the last statement of a function which returns a value isn't
> a return statement.
>
> We don't want this diagnosed:
>
> int fred(void)
> {
> if (this)
> return that;
> else
> return other;
> }
>
> Basically we want the last statement to to be a "tail statement",
> which is defined as a return statement, or else a statement which
> has a tail statement in every tail position.

Diagnosing this fully is difficult. It requires analysis of the code to
be able to determine if control flow ever runs into the end of the
function, and then whether 'return' is executed when the last statement
in the function is complex.

However, my example is simple: there are clearly zero return statements;
at least one is needed for a value-returning function.

And a variation of my test is 'int fred{return;}'. Here, any return
obviously needs a value, and that is very easy to check.

gcc will report a warning here; clang an error; and tcc nothing.

You'd think this is a no-brainer.

(My own language compiler has no problem detecting whether a complex
last statement/expression yields a suitable return value, but it does no
analysis to detect whether that last expression is ever executed. So
sometimes a dummy return value is needed.

I do the same in my C compiler, but there you do encounter functions
with no final return <value>, which have to be allowed because they
always exit earlier. So I can't apply my check. But you need to use -old
to get away without that final return.)

>> Imagine buying a car with no brakes. Oh, nothing wrong that, only if you
>
> Imagine buying a power transistor with no thermal shutoff.
>
> Wait, that's pretty much all of them.
>
> Engineering products and consumer products are different.
>
> A transistor has good reasons for being the way it is; a language
> allowing control flow to fall off the end without a return value
> isn't such a good reason. We can't compare the justification.

If such a function was used in a library module within automotive
software that controlled the brakes, then yes there is justification.

Why make C even more crazily unsafe than it already is? You should have
to fight to allow unsafe code, not have to fight to make it safe!

On 01/09/2023 23:34, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:

>> Fortran has been around longer than C. Do its latest compilers give
>> priority to being able to build code unchanged from the 60s and 70s?
>
> I strongly suspect, yes.
>

Apparently not. These are the instructions attached to an old-style
Fortran Hello program:

C How to compile:
C gfortran -std=legacy -c hello-world.f

Notice the 'legacy' option. So, unlike most C compilers, you have to
explicitly enable the ability to build old-style programs.

This corresponds more or less with my '-old' option. Although that is
mainly to allow things I would rather prohibit, but that can be
encountered in existing code.

Including, unfortunately, code written yesterday. Since one consequence
of being lax by default is that it doesn't curtail the use of deprecated
features.

On 9/2/23 2:39 AM, Bart wrote:
> There is apparently no one C language that says that 'int fred(void){}'
> must be illegal.

You seem a bit stuck on this.

What simple rule would you add to make it actually a diagnosable condition?

You can't just require a return statement at the end of functions,
because some code might not reach the end of the function to "fall off",
so that would be forcing unreachable code.

You can't require a return statement if the end was reachable, because
that is a condition that can't always be determined.

On 02/09/2023 15:33, Richard Damon wrote:
> On 9/2/23 2:39 AM, Bart wrote:
>> There is apparently no one C language that says that 'int
>> fred(void){}' must be illegal.
>
> You seem a bit stuck on this.

It's the example I've been using to show the diverse responses from
compilers. That is, Pass, Fail, Warn.

(I thought UB refered to undefined behaviour of the program, not the
compiler!)

> What simple rule would you add to make it actually a diagnosable condition?

A simple one would be that be a non-void function should have at least
one 'return' statement. It won't catch all cases of running into the end
of the function, but will catch some.

I posted also the example 'int fred(void){return;}', which gcc takes a
bit more seriously, but still not enough to fail the program. This one
is very easy to check.

> You can't just require a return statement at the end of functions,
> because some code might not reach the end of the function to "fall off",
> so that would be forcing unreachable code.
>
> You can't require a return statement if the end was reachable, because
> that is a condition that can't always be determined.

This is what I do in my languages: the last expression in a function (as
it is expression-based), must yield a suitable return value. A dummy
value is needed in some cases.

That's not possible to enforce in C because of existing practice. I try
to do it, and it requires the legacy option to allow a missing return value.

On 01/09/2023 23:29, Bart wrote:

> And yet, it is possible to create a compiler that gives the common-sense
> results that one would expect. Except I'm not seeing it.
>

That's because you can't tell the difference between "common sense" and
"Bart's personal opinions and preferences, as well as his
misunderstandings of the C language".

> What do you expect the results of compiling this program with -c to be:
>
>     int fred(void){}
>
> Here are the results I get:
>
>                   Warnings Errors
>
>      gcc          -        -
>      tcc          -        -
>      clang        1        -
>      msvc         1        -
>      gcc -Wall    1        -
>      lccwin32     1        -
>      bcc          -        1
>
>
> The problem with that function, in case you haven't spotted it, is that
> it does not return an 'int' value.

I refer you to the C standards, section 6.9.1 "Function definitions",
paragraph 12 - "Unless otherwise specified, if the } that terminates a
function is reached, and the value of the function call is used by the
caller, the behaviour is undefined".

It is perfectly legal C to have a function defined as returning an "int"
but not having a "return" statement with a value that can be converted
to an "int".

Calling that function, and using the returned value, would be undefined
behaviour. But the function definition itself is not.

Now, you can well argue that that is a poor choice of definition for the
language. I'd agree - it stems from the historic days of C before
prototypes, when functions were assumed to take an unspecified number of
"int" parameters and return an "int" value, before "void" was part of
the language.

However, regardless of whether you like it or not, the function
definition here is perfectly legal C, and can be used safely and
correctly with fully defined behaviour. A compiler that does not accept
that code and compile it would therefore be rejecting correct C code.

Equally clearly, it is likely that the code is in error, and the
function could easily be used incorrectly - so a warning is definitely
appropriate.

So here I would say "clang", "msvc", "gcc -Wall" and "llwin32" did a
good job, while "gcc", "tcc" did a poor job (no warning), and "bcc" was
simply incorrect as a C compiler.

I can fully agree with you that the function was bad, and it is a good
thing to help developers write good code. I can fully agree with you
that the C language would be better if it were defined more strictly
here. But the job of a C compiler is to compile C code as the language
is defined - it is not the job of a C compiler to dictate the compiler
writer's idea of what he thinks C should have been.

On 02/09/2023 02: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.

And Ben's choice here would be unacceptable to me, and to a lot of other
people, because I generally /do/ want some gcc extensions. (My job
would be impossible without some of them.) And I can pretty much
guarantee that Ben's preferences for warning options and other code
generation options will be different than mine (especially since mine
can vary a little between projects). That's why it is great that gcc
has lots of flexibility, and can be adapted to different needs and
preferences. One size does not fit all in the world of programming.

On 02/09/2023 03:43, Kaz Kylheku wrote:
> On 2023-09-02, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> Generally gcc in default mode gives sensible warnings which either indicate
>
> For values of "default mode" being -Wall, of course.

And "-O2".

On 02/09/2023 03:13, Malcolm McLean wrote:

> Generally gcc in default mode gives sensible warnings which either indicate
> actual bugs, or odd programming which should be cleaned up.

The warnings that gcc gives when run without additional flags are
certainly very clear indications of problems. But it accepts a huge
range of almost certainly incorrect code without comment unless you
specify warning flags. gcc without flags is very weak in terms of
warnings - due mainly to the need for historical compatibility. Using
gcc without flags as a development tool is incompetence.

> Then you can
> ramp up the warning level to get a huge amount, but they tend to be things
> like warnings about mixed mode arithemetic because size_t is unsigned,
> which is very unlikely to cause an error.

If only gcc had a way to pick the warnings that are appropriate for the
type of programming in question... oh, wait, it does!

I have often used the warnings that target mixed sign arithmetic,
precisely because they /are/ likely to cause errors. This, of course,
depends entirely on the kind of code in question - which is why warnings
like this are controlled by flags.

>>
>>> 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?
>>
> In most software, every option you provide represents a failure rather than
> an enhancement.

In most of your posts, any use of the word "most" is an indication that
you are about to write completely unsubstantiated nonsense. This post
did not disappoint.

On 01/09/2023 20:59, Scott Lurndal wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>>>> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not
>>>> overruled by command line warning options, but there may be a way to
>>>> force these to be ignored.
>>>
>>> Those don't always work. At least this doesn't:
>>>
>>> #pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
>>>
>>> It works on Windows gcc but not WSL gcc.
>>
>> "WSL gcc" is not the designation of a version of GCC.
>>
>> Not all versions of GCC have the same -W options because, doh,
>> new ones get added over time.
>>
>> Unfortunately, when you give a new -W option to an old GCC,
>> it has a fit about an unrecognized option and bails.
>>
>> Projects that want to take advantage of new options, but still
>> work with olde GCC's, have a slight problem.
>>
>> One approach is to detect what options work, in your ./configure script.
>
> Or in the Makefile if you don't use autoconf.
>
> GCC_HAS_GENERIC_TUNING := $(shell expr `$(CXX) -dumpversion | cut -f2 -d. ` \>= 2)
> GCC_HAS_MCRC32 := $(shell expr `$(CXX) -E -mcrc32 /dev/null 2>/dev/null; echo $$?` == 0)
>
> IS_GCC_MAJOR_VER_4 := $(shell if [ `$(CXX) -dumpversion | cut -f1 -d. ` -eq 4 ]; then echo 1; else echo 0; fi )
>

Or even better, since this is a pragma in the source code, have it
wrapped in conditional compilation that checks first for gcc, then for
the gcc version. Sure, it can be a bit ugly, but it only needs to be
written once and copied out verbatim by the code generator (or put in a
common header file for the rest of us), and godbolt.org makes it very
easy to test with different gcc versions.

On 9/2/23 8:26 AM, Bart wrote:
> On 02/09/2023 15:33, Richard Damon wrote:
>> On 9/2/23 2:39 AM, Bart wrote:
>>> There is apparently no one C language that says that 'int
>>> fred(void){}' must be illegal.
>>
>> You seem a bit stuck on this.
>
> It's the example I've been using to show the diverse responses from
> compilers. That is, Pass, Fail, Warn.

A compiler that "fails" this program is non-conforming.

A compiler is allowed to "warn" about anything it wants, and that just
becomes a "Quality of Implementation" Issue.

>
> (I thought UB refered to undefined behaviour of the program, not the
> compiler!)

Nope, some UB refers to "compiler" behavior. Some "errors" are allowed
to not be diagnosed (normally because diagnosing them isn't easy to
define) but some system might do the extra work to allow them to find them.

Some sorts of errors get found later, like a link time.

>
>> What simple rule would you add to make it actually a diagnosable
>> condition?
>
> A simple one would be that be a non-void function should have at least
> one 'return' statement. It won't catch all cases of running into the end
> of the function, but will catch some.

But there can be perfectly valid functions that don't meet that requirement.

In fact, most of the programs I write have such a function, called main.

These programs all are started and will NEVER end, in part because they
don't have anything to exit to (they run on machines without an OS).

>
> I posted also the example 'int fred(void){return;}', which gcc takes a
> bit more seriously, but still not enough to fail the program. This one
> is very easy to check.

So, you don't think implmentations should be allowed to provide extensions?

>
>> You can't just require a return statement at the end of functions,
>> because some code might not reach the end of the function to "fall
>> off", so that would be forcing unreachable code.
>>
>> You can't require a return statement if the end was reachable, because
>> that is a condition that can't always be determined.
>
> This is what I do in my languages: the last expression in a function (as
> it is expression-based), must yield a suitable return value. A dummy
> value is needed in some cases.

So, you language forces unneeded code. That's ok.

You also don't need to support the old code that C tries to. Back before
void was added, so functions always had a return value, even if not
specified, but it was allowed to just fall off the end without a return
to do nothing.

>
> That's not possible to enforce in C because of existing practice. I try
> to do it, and it requires the legacy option to allow a missing return
> value.

Yep, one of the advantages of being willing to throw out old code.

One guiding principle of the C Standard Committee is to try to respect
the validity of the existing code base of applications and library.

This does result in some things that might seem sub-optimal if you are
just looking at new stuff.

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

You can even add :

int main(int argc, char * argv[]) {
if (arc == 2) return boo();
}

The whole thing is valid C, and is only undefined behaviour if the
executable is called with one argument.

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.

>
> Note carefully that I am describing the requirements given by the C
> standard, not expressing an opinion on whether they're good or bad.
>
> Now, what was your point, and how does `int fred(void){}` illustrate it?
>

On 02/09/2023 12:57, Bart wrote:
> On 02/09/2023 02:12, Kaz Kylheku wrote:
>> On 2023-09-02, Bart <bc@freeuk.com> wrote:
>>> 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.
>>>
>>> But in this group, so many people have argued that black is white, or
>>> vice versa, that nothing surprises me any more.
>>
>> It's a good idea to produce a diagnostic in cases when it's obvious
>> that the control graph of the function reaches the end without
>> hitting a return statement.
>>
>> C allowing the return, provided that the caller doesn't use the
>> value, is a bit of a relic. Early C worked that way because
>> every function returned int, but not every function needed
>> to return anything. It's not a good feature today.
>>
>> Keith seems to have mentioned that something had been done about it
>> in C23?
>>
>> Anyway, compilers can diagnose it even though it's not required.
>>
>> It would be significantly more difficult to work with C without
>> compilers that go beyond required diagnostics.
>>
>> You can't just blindly diagnose this as a syntactic issue; i.e.
>> that the last statement of a function which returns a value isn't
>> a return statement.
>>
>> We don't want this diagnosed:
>>
>>    int fred(void)
>>    {
>>      if (this)
>>        return that;
>>      else
>>        return other;
>>    }
>>
>> Basically we want the last statement to to be a "tail statement",
>> which is defined as a return statement, or else a statement which
>> has a tail statement in every tail position.
>
> Diagnosing this fully is difficult. It requires analysis of the code to
> be able to determine if control flow ever runs into the end of the
> function, and then whether 'return' is executed when the last statement
> in the function is complex.
>
> 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;
}

>
> And a variation of my test is 'int fred{return;}'. Here, any return
> obviously needs a value, and that is very easy to check.
>
> gcc will report a warning here; clang an error; and tcc nothing.

That's a constraint error (section 6.8.6.4p1), so it requires a
diagnostic (regardless of whether or not "fred" is used, or how it is
used). A diagnostic can be an error or a warning. (I personally would
prefer an error here.)

>
> You'd think this is a no-brainer.
>

You'd be surprised how often reality is vastly more complicated than
what you think of as a "no-brainer". Your programming world is so small
and sheltered, and you never offer a thought to anyone else or their
needs and preferences, so you miss pretty much every nuance involved.

On 2023-09-02, Bart <bc@freeuk.com> wrote:
> 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.

Diagnostics are truths about a program.

So what you're saying is that you want to shutter yourself and the users
against the discovery of truths, and new kinds of truth.

I've experienced situations in which a new diagnostic added in
a new release of GCC uncovered a latent bug.

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

Right, never has been, so that is what it is.

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

That's right; a decision in a config script or any of the inputs
to those tools can change the content of a program.

If you don't like it, go complain to the author.

> 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 times, this is too chaotic for my taste. It is just

Yes, you've written about your taste, and nothing but your taste, many
times. It is well-known.

Most people who develop those chaotic programs are not reading this
newsgroup. They are not here, therefore even if they responded
to such complaints, they won't do so.

> far too open-ended. And it currently panders far too much to ancient
> legacy code and options in /all/ those languages, scripts and tools.

Old code has to build and work. Fact of life. People don't rewrite
milions of lines because the language has changed.

> Funny how discussions here often focus on some exact wording in the C
> standard, while the rest of it leaves gaping holes in the spec large
> enough to drive a bus through.

That's, sort of, a variation of the Tu Quoque fallacy. If we are
discussing the correctness of some particular construct, we are not in
that moment concerned with the rest of the program; that is assumed to
be correct.

That that there could be bugs elsewhere in the program, in connection
with the language being loose, cannot be used as an excuse not to focus
on some part of it.

> (I've working on a new systems language where instead of there being
> exactly one, fixed language that needs nothing else to build projects,
> there will a closely integrated, embedded scripting language.

That's original; nobody in the C world uses embedded scripting
languages for flexibility.

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

On 2023-09-02, Bart <bc@freeuk.com> wrote:
> On 02/09/2023 02:12, Kaz Kylheku wrote:
>> Basically we want the last statement to to be a "tail statement",
>> which is defined as a return statement, or else a statement which
>> has a tail statement in every tail position.
>
> Diagnosing this fully is difficult.

Breaking news: the C language historically ducks out of "difficult"!

It's only worth doing fully or not at all (within reasonable limits of
static analysis: not trying to solvve the halting problem).

> be able to determine if control flow ever runs into the end of the
> function, and then whether 'return' is executed when the last statement
> in the function is complex.

No; Keith nailed it. We don't care about return, specifically. We want
to diagnose the situation that the end of the function is reachable.

A return statement before the end of the function is one way
that the end is unreachable, and thus okay. There are other ways
that reaching it can be blocked.

We could have it so that it has to be "statically obvious" that
the end of the function is not reached, where by "statically obvious"
we identify all dead code implicated by constant expressions.
If the end of the function is eliminated as dead code, then it's
not reached.

Thus this diagnoses:

int fred(void)
{
extern int always_true(void);

while (always_true()) {

}
}

This doesn't:

int fred(void)
{
while (1) {

}
}

The previous one will be a nuisance diagnosic since the always_true
function always returns true.

If the belief is correct, why not restructure the code:

int fred(void)
{
extern int always_true(void);

for (;;) {
always_true(); // call for its side effect only

}
}

> And a variation of my test is 'int fred{return;}'. Here, any return
> obviously needs a value, and that is very easy to check.
>
> gcc will report a warning here; clang an error; and tcc nothing.
>
> You'd think this is a no-brainer.

The only no-brainer is that tcc is deficient.

ISO C99 says, in a Constraints paragraph: "A return statement without an
expression shall only appear in a function whose return type is void."
Thus, it requires a diagnostic.

I'm suspect it's been there since ANSI C 1989.

That is one diagnostic you don't want to put to a --pedantic
mode, either. It's not a reasonable local language extension to allow
"return;" in a function with non-void return type.

Of course, Your Language could never be deficient in this way,
because you're the only arbiter of what is correct. Do you even
have a document which could differ from what is implemented?

> (My own language compiler has no problem detecting whether a complex
> last statement/expression yields a suitable return value, but it does no
> analysis to detect whether that last expression is ever executed. So
> sometimes a dummy return value is needed.

That's ugly:

{
if (this)
return that;
else
return other_thing;

return 0; // shut up dumb compiler?
}

it does the job of reducing errors, but smacks of immaturity.

>>> Imagine buying a car with no brakes. Oh, nothing wrong that, only if you
>>
>> Imagine buying a power transistor with no thermal shutoff.
>>
>> Wait, that's pretty much all of them.
>>
>> Engineering products and consumer products are different.
>>
>> A transistor has good reasons for being the way it is; a language
>> allowing control flow to fall off the end without a return value
>> isn't such a good reason. We can't compare the justification.
>
> If such a function was used in a library module within automotive
> software that controlled the brakes, then yes there is justification.

There is justification in using a good compiler with tons of warnings,
which enforces the MISRA coding recommendations and such.

> Why make C even more crazily unsafe than it already is? You should have
> to fight to allow unsafe code, not have to fight to make it safe!

That's simply not the kind of tool that C is, and will likely never
evolve into that. In the foreseeable future, it's compilers,
run-time tools, static analaysis tools, around a language that stays
more or less the same.

The newsgroups for safe-by-default languages are not immune to
trolling, like someone complaining that all the default safety
gets in the way of just telling the machine what to do, and look
how much shorter this C example is!

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

On 2023-09-02, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 23:34, Kaz Kylheku wrote:
>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>
>>> Fortran has been around longer than C. Do its latest compilers give
>>> priority to being able to build code unchanged from the 60s and 70s?
>>
>> I strongly suspect, yes.
>>
>
> Apparently not. These are the instructions attached to an old-style
> Fortran Hello program:
>
> C How to compile:
> C gfortran -std=legacy -c hello-world.f

There are some old C programs that will need dialect options also.

One program that needs a legacy option doesn't mean anything.

The evolution of C has been marked by dogged adherence to backward
compatibility.

Not so sure about Fortran.

Fortran has radically changed since its inception. It has some OOP
features and operator overloading and such.

Some features were obsoleted long ago, like hollerith strings.

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

On 02/09/2023 17:03, Richard Damon wrote:
> On 9/2/23 8:26 AM, Bart wrote:

>>> What simple rule would you add to make it actually a diagnosable
>>> condition?
>>
>> A simple one would be that be a non-void function should have at least
>> one 'return' statement. It won't catch all cases of running into the
>> end of the function, but will catch some.
>
> But there can be perfectly valid functions that don't meet that
> requirement.
>
> In fact, most of the programs I write have such a function, called main.

A special exception has to be made for main. (Note that Pico C doesn't
have that exception, but it is a very small compiler.)

> These programs all are started and will NEVER end, in part because they
> don't have anything to exit to (they run on machines without an OS).

If you have a function that you know will never return (becauses it
stays in a loop, or terminates, here or in a nested function), then why
would you give it a return type in the first place?

Maybe /that/ is the thing that should be pointed out, and maybe that is
also the error that has been made.

>>
>> I posted also the example 'int fred(void){return;}', which gcc takes a
>> bit more seriously, but still not enough to fail the program. This one
>> is very easy to check.
>
> So, you don't think implmentations should be allowed to provide extensions?

A meaningless, dangerous extension? No. What exactly would be the
purpose of it? To avoid having to write a superfluous:

return 0;

to satisfy the language's type system? Such a statement will likely be
elided by the compiler's optimiser anyway, or at least the instruction
to load the return value.

Since I would expect the compiler to inject a return instruction in the
generated code. (For this reason, a return statement at the end of a
void function can be optional.)

>>
>>> You can't just require a return statement at the end of functions,
>>> because some code might not reach the end of the function to "fall
>>> off", so that would be forcing unreachable code.
>>>
>>> You can't require a return statement if the end was reachable,
>>> because that is a condition that can't always be determined.
>>
>> This is what I do in my languages: the last expression in a function
>> (as it is expression-based), must yield a suitable return value. A
>> dummy value is needed in some cases.
>
> So, you language forces unneeded code. That's ok.

My languages allow early returns from a function; some don't.

But for functions which return a type T, they require that the body of
the function yields a value of type T.

So it is somewhat stricter type checking. Type checking doesn't pay heed
to control flow within the function. If it did, and that allowed you to
not have a proper type for the function body, it could mean that when
you later comment out this early return:

return x

that the rest of function, which could terminate with complex if, case
or switch statement, could now fail a type check. It is better that it
complies no matter what.

> You also don't need to support the old code that C tries to. Back before
> void was added, so functions always had a return value, even if not
> specified, but it was allowed to just fall off the end without a return
> to do nothing.

That explains a lot. Then the solution is easy: require '-std=legacy'
like Fortran does to compile ancient programs.

If people say there old makefiles that would need tweaking, THEN FIX
THOSE MAKEFILES, rather than allow generations of programmers to keep
writing both sloppy, dangerous code, and sloppy makefiles that make
assumptions.

> Yep, one of the advantages of being willing to throw out old code.

I don't throw it out; I require an option like the one I suggested.

> One guiding principle of the C Standard Committee is to try to respect
> the validity of the existing code base of applications and library.

Sure, but is the guiding principle also that compilers mustn't be
allowed to require an option to support existing code written to older,
less safe standards?

Because so many people use compilers without a set of options to specify
the language standard, dialect and level of strictness, it means nothing
stops them continuing to write old-style unsafe code. Which in turn
makes it harder to deprecate such code, as there's so much of it.

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

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

> You'd be surprised how often reality is vastly more complicated than

Exactly. Some of us are trying to make it less complicated. And along
the way, end up writing safer, less buggy code too!

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.

On 02/09/2023 17:29, Kaz Kylheku wrote:
> On 2023-09-02, Bart <bc@freeuk.com> wrote:

> That's original; nobody in the C world uses embedded scripting
> languages for flexibility.

It won't be like mine. Note the words 'closely integrated', which means
specific support within the host language.

Most such attempts are dog's dinners. And have they made of the world of
build systems any simpler, smaller or easier? Not that I've noticed!

Bart <bc@freeuk.com> writes:
[...]
> I posted also the example 'int fred(void){return;}', which gcc takes a
> bit more seriously, but still not enough to fail the program. This one
> is very easy to check.

That's a constraint violation since C99. See N1570 6.8.5.4p1.

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

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> ISO C99 says, in a Constraints paragraph: "A return statement without an
> expression shall only appear in a function whose return type is void."
> Thus, it requires a diagnostic.
>
> I'm suspect it's been there since ANSI C 1989.

No, it was introduced in C99. C90 says:

Constraints

A return statement with an expression shall not appear in a function
whose return type is void

Semantics
...
If a return statement without an expression is executed. and the
value of the function call is used by the caller, the behavior is
undefined. Reaching the } that terminates a function is equivalent
to executing a return statement without an expression.

This was to cater to pre-ANSI code that used implicit int where modern
code would use a void return type. For example, a function that
performs some action and doesn't return a value might be defined in
modern C as:

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

In modern C, it might be written as:

void do_something(void) {
if (already_done) return;
do_the_thing();
}

The function implicitly returns int, but the return statement without an
expression was appropriate because the caller would not use the result.

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

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

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

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.

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

> But in this group, so many people have argued that black is white, or vice
> versa, that nothing surprises me any more.

No one is doing that. C is what it is, but you get frustrated when
people don't join you in wailing and gnashing of teeth.

--
Ben.

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

--
Ben.