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

> On 2023-09-07, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>> [...]
>>
>>>> Compilers will still accept functions which return
>>>> garbage values. Presumably for backwards compatibility,
>>>
>>> I suspect it's also because detecting the cases that are actual
>>> errors is hard [...]
>>
>> Besides being theoretically impossible, it's not practical
>> because of C allowing separate compilation. To get an answer
>> (potentially) requires examining the entire program.
>
> But why would that even be a goal?
>
> If you need to know what a function in another translation unit
> does in order to know whether or not the function "falls off the end",
> that's a code smell.

Really? If I have

int do_lots_of_stuff(...) {
if (this) ...
else if (that) ...
else if (the other) ...
abort_with_error_message("Don't know what to do.");
}

that's smelly code? Of course, if C23 happens as planned I am permitted
to declare

[[noreturn]] void abort_with_error_message(const char *);

but I don't have to (and I'd have to hide that attribute for compilers
that are catching up).

> Do you have in mind examples of situations in which false positives
> would cause problems, or even just irk the programmer?

Well I'd be irked by having to write a 'return 0;' there just to shut
the compiler up. But, to be clear, it's a tiny irk.

--
Ben.

On 07/09/2023 16:28, Ben Bacarisse wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-07, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>> [...]
>>>
>>>>> Compilers will still accept functions which return
>>>>> garbage values. Presumably for backwards compatibility,
>>>>
>>>> I suspect it's also because detecting the cases that are actual
>>>> errors is hard [...]
>>>
>>> Besides being theoretically impossible, it's not practical
>>> because of C allowing separate compilation. To get an answer
>>> (potentially) requires examining the entire program.
>>
>> But why would that even be a goal?
>>
>> If you need to know what a function in another translation unit
>> does in order to know whether or not the function "falls off the end",
>> that's a code smell.
>
> Really? If I have
>
> int do_lots_of_stuff(...) {
> if (this) ...
> else if (that) ...
> else if (the other) ...
> abort_with_error_message("Don't know what to do.");
> }
>
> that's smelly code?

I will often write something like :

// "opt" must be 1, 2, or 3
int do_stuff(int opt) {
switch (opt) {
case 1 : return do_stuff_1();
case 2 : return do_stuff_2();
case 3 : return do_stuff_3();
}
__builtin_unreachable();
}

I think the "__builtin_unreachable();" is a good indication to both the
compiler and the reader that this line is never reached. Of course,
this is a gcc/clang extension, but in real code you can have a macro
that is adapted to suit the compiler. (Other compilers have their own
alternative, and "assert(false)" is a reasonable fall-back.)

> Of course, if C23 happens as planned I am permitted
> to declare
>
> [[noreturn]] void abort_with_error_message(const char *);

With C11, you can write :

_Noreturn void abort_with_error_message(const char *);

So you don't have to wait until C23 (unless you really want the
attribute syntax).

>
> but I don't have to (and I'd have to hide that attribute for compilers
> that are catching up).
>
>> Do you have in mind examples of situations in which false positives
>> would cause problems, or even just irk the programmer?
>
> Well I'd be irked by having to write a 'return 0;' there just to shut
> the compiler up. But, to be clear, it's a tiny irk.
>

On 07/09/2023 15:28, Ben Bacarisse wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:

>> Do you have in mind examples of situations in which false positives
>> would cause problems, or even just irk the programmer?
>
> Well I'd be irked by having to write a 'return 0;' there just to shut
> the compiler up. But, to be clear, it's a tiny irk.

Having to do so at the end of main() must have irked enough people that
most C compilers allow it to be left out.

But, in the case of main, they also do something special; for this program:

int fred(void) {}
int main(void) {}

gcc, with noise removed, produces this x64 code:

fred:
push rbp
mov rbp, rsp
nop
pop rbp
ret

main:
push rbp
mov rbp, rsp

mov eax, 0
pop rbp
ret

Can you spot the difference between the two functions?

Yes, in main(), it ensures the return value is 0, instead of being
undefined. But it's not bothered about that for fred(), although it
could have done the same.

Why the special dispensation for main(), and not for user functions? And
don't say because the Standard stipulates; it could have stipulated for
user functions too!

Bart <bc@freeuk.com> writes:
>On 07/09/2023 15:28, Ben Bacarisse wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>>> Do you have in mind examples of situations in which false positives
>>> would cause problems, or even just irk the programmer?
>>
>> Well I'd be irked by having to write a 'return 0;' there just to shut
>> the compiler up. But, to be clear, it's a tiny irk.
>
>Having to do so at the end of main() must have irked enough people that
>most C compilers allow it to be left out.
>
>But, in the case of main, they also do something special; for this program:
>
> int fred(void) {}
> int main(void) {}
>
>
>gcc, with noise removed, produces this x64 code:
>
> fred:
> push rbp
> mov rbp, rsp
> nop
> pop rbp
> ret
>
> main:
> push rbp
> mov rbp, rsp
>
> mov eax, 0
> pop rbp
> ret
>
>Can you spot the difference between the two functions?
>
>Yes, in main(), it ensures the return value is 0, instead of being
>undefined. But it's not bothered about that for fred(), although it
>could have done the same.

When I compile that with gcc[-O2], I get:

0000000000400400 <main>:
400400: f3 c3 repz retq
400402: 66 90 xchg %ax,%ax
00000000004004f0 <fred>:
4004f0: f3 c3 repz retq
4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
4004f9: 00 00 00
4004fc: 0f 1f 40 00 nopl 0x0(%rax)

On 2023-09-07, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Thursday, 7 September 2023 at 07:10:49 UTC+1, Kaz Kylheku wrote:
>>
>> I'm quite puzzled by your angle which seems to be that if the
>> reachability diagnostic cannot be done accurately, due to theory,
>> translation units and run-time conditions/inputs, then it's
>> a bad diagnostic not worth doing (or at least not worth having
>> right in the language). Pardon me if I'm misconstruing antyhing.
>>
> Take this one.
>
> int gamemainloop(void)
> {
> if (allocatememorybuffers() == -1)
> return -1; // out of memory;
> if (hardwaretest() == FAIL)
> return -2; // proper hardware not installed
> loopforever(); // update / render loop, never returns
> }
>
> Obviously to prove that loopforever loops forever we need to examine it.

Unless there is a good reason for the int return type, it should be
changed to void.

If it doesn't return, it deosn't return int; it returns nothing.

> And even if we could, its the halting problem - most real programs written
> by humans can be trivially proven to either halt or run forever, but it's hard
> to write that requirement into a programming language.

It's not merely hard; it's unwise to even contemplate. Equally unwise
to be deterred from making useful requirements.

>> Do you have in mind examples of situations in which false positives
>> would cause problems, or even just irk the programmer?
>>
> We could put a return 0 at the bottom of the fucntion, but that would falsely
> imply that in some circumstances it returns 0.

That goes hand-in-hand with its declaration, which falsely implies that
the function returns int, do do which it has to return.

If we believe that loopforever() doesn't return, and we cannot change
the return type for whatever reason, we could put an abort() call at the
end of the function.

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

On 07/09/2023 16:16, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/09/2023 15:28, Ben Bacarisse wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>>> Do you have in mind examples of situations in which false positives
>>>> would cause problems, or even just irk the programmer?
>>>
>>> Well I'd be irked by having to write a 'return 0;' there just to shut
>>> the compiler up. But, to be clear, it's a tiny irk.
>>
>> Having to do so at the end of main() must have irked enough people that
>> most C compilers allow it to be left out.
>>
>> But, in the case of main, they also do something special; for this program:
>>
>> int fred(void) {}
>> int main(void) {}
>>
>>
>> gcc, with noise removed, produces this x64 code:
>>
>> fred:
>> push rbp
>> mov rbp, rsp
>> nop
>> pop rbp
>> ret
>>
>> main:
>> push rbp
>> mov rbp, rsp
>>
>> mov eax, 0
>> pop rbp
>> ret
>>
>> Can you spot the difference between the two functions?
>>
>> Yes, in main(), it ensures the return value is 0, instead of being
>> undefined. But it's not bothered about that for fred(), although it
>> could have done the same.
>
> When I compile that with gcc[-O2], I get:
>
> 0000000000400400 <main>:
> 400400: f3 c3 repz retq
> 400402: 66 90 xchg %ax,%ax
> 00000000004004f0 <fred>:
> 4004f0: f3 c3 repz retq
> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
> 4004f9: 00 00 00
> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)

Which means what? A failed attempt to bamboozle Bart?

On godbolt.org using -O2, the latest MSVC, Clang, Zig CC, gcc and icc
compilers for x64 show clear instructions that clear eax for main(), not
so for fred().

On PowerPC, main has a 'li 3,0' instruction that doesn't appear in fred.

On MIPS, it is 'mov $2, $0'.

On one ARM64 compiler, it has 'mov r0, #0'.

So clearly, there is a pattern of the compiler inserting code to clear
the return value from main().

Which is very convenient in avoiding the user having to write 'return
0;' in ONE function in an entire application, never mind the 1000s of
user functions that could benefit from that, but are left to return
garbage if control falls off the end of the function.

But back to your nonsense: F3 C3 means 'ret', as does 'C3'. It would be
useful to show the whole of that main() function to see what you've left
out.

(What value does your main() actually return if you run into the end?
/Does/ it actually run into the end? And if it is zero, how does it get
there?

Also, why is your code generating such crap?)

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

> With C11, you can write :
>
> _Noreturn void abort_with_error_message(const char *);
>
> So you don't have to wait until C23 (unless you really want the attribute
> syntax).

I somehow missed that in C11. Thanks.

--
Ben.

On 2023-09-07, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> With C11, you can write :
>>
>> _Noreturn void abort_with_error_message(const char *);
>>
>> So you don't have to wait until C23 (unless you really want the attribute
>> syntax).
>
> I somehow missed that in C11. Thanks.

By the way I agree with you that the code doesn't smell, since the
abort_with_error_message is like abort.

If we are going to have warnings about reachable function tails,
we need a way to declare that some our functions are abort-like.

And, we have it.

Otherwise we might have to resort to

#define abort_with_error_message(msg) \
do {
fprintf(stderr, "%s\n", msg);
abort();
} while (0)

I'm assuing that whatever rule we are working around is sanely designed
and recognizes abort, longjmp and exit as non-returning.

This approach adds code bloat.

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

Bart <bc@freeuk.com> writes:
>On 07/09/2023 16:16, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 07/09/2023 15:28, Ben Bacarisse wrote:
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>
>>>>> Do you have in mind examples of situations in which false positives
>>>>> would cause problems, or even just irk the programmer?
>>>>
>>>> Well I'd be irked by having to write a 'return 0;' there just to shut
>>>> the compiler up. But, to be clear, it's a tiny irk.
>>>
>>> Having to do so at the end of main() must have irked enough people that
>>> most C compilers allow it to be left out.
>>>
>>> But, in the case of main, they also do something special; for this program:
>>>
>>> int fred(void) {}
>>> int main(void) {}
>>>
>>>
>>> gcc, with noise removed, produces this x64 code:
>>>
>>> fred:
>>> push rbp
>>> mov rbp, rsp
>>> nop
>>> pop rbp
>>> ret
>>>
>>> main:
>>> push rbp
>>> mov rbp, rsp
>>>
>>> mov eax, 0
>>> pop rbp
>>> ret
>>>
>>> Can you spot the difference between the two functions?
>>>
>>> Yes, in main(), it ensures the return value is 0, instead of being
>>> undefined. But it's not bothered about that for fred(), although it
>>> could have done the same.
>>
>> When I compile that with gcc[-O2], I get:
>>
>> 0000000000400400 <main>:
>> 400400: f3 c3 repz retq
>> 400402: 66 90 xchg %ax,%ax
>> 00000000004004f0 <fred>:
>> 4004f0: f3 c3 repz retq
>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
>> 4004f9: 00 00 00
>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)
>
>Which means what? A failed attempt to bamboozle Bart?

It means that different compilers (the above was GCC 4.8.3)
do different things even between versions.

GCC 9.3.0

0000000000400460 <fred>:
400460: c3 retq
400461: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
400468: 00 00 00
40046b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)

0000000000400360 <main>:
400360: 31 c0 xor %eax,%eax
400362: c3 retq
400363: 90 nop

But ultimately, nobody but you cares what code is generated
in your contrived example.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>David Brown <david.brown@hesbynett.no> writes:
>
>> With C11, you can write :
>>
>> _Noreturn void abort_with_error_message(const char *);
>>
>> So you don't have to wait until C23 (unless you really want the attribute
>> syntax).
>
>I somehow missed that in C11. Thanks.

And gcc has supported __attribute((noreturn))__ since gcc 2.5.

Bart <bc@freeuk.com> writes:

> On 07/09/2023 15:28, Ben Bacarisse wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>>> Do you have in mind examples of situations in which false positives
>>> would cause problems, or even just irk the programmer?
>> Well I'd be irked by having to write a 'return 0;' there just to shut
>> the compiler up. But, to be clear, it's a tiny irk.
>
> Having to do so at the end of main() must have irked enough people that
> most C compilers allow it to be left out.

That seems unlikely but I don't know the reason. It never irked me
because, unlike the case we are talking about (which you cut from the
reply), the return statement was not unnecessary (at least in the
environment I used). Maybe there was a lot of code running on systems
where people tended to ignore the returned value so it got left off a
lot? Anyway, it's not the same as the case in question because the
return used to be important.

> Why the special dispensation for main(), and not for user functions?

I would guess because there is always only one main function. It is
inherently special, so there is negligible cost to any special
treatment. Having to provide a value for every function, including
those that don't need one (like the example you cut), is the kind of
thing other languages usually do. Even thought the cost might be very,
very low it still feels un-C-like.

--
Ben.

scott@slp53.sl.home (Scott Lurndal) writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>David Brown <david.brown@hesbynett.no> writes:
>>
>>> With C11, you can write :
>>>
>>> _Noreturn void abort_with_error_message(const char *);
>>>
>>> So you don't have to wait until C23 (unless you really want the attribute
>>> syntax).
>>
>>I somehow missed that in C11. Thanks.
>
> And gcc has supported __attribute((noreturn))__ since gcc 2.5.

I knew that! I was limiting myself to C (which I would call ISO C if
this were not a largely Bart-driven thread).

--
Ben.

On 07/09/2023 17:15, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/09/2023 16:16, Scott Lurndal wrote:

>>> When I compile that with gcc[-O2], I get:
>>>
>>> 0000000000400400 <main>:
>>> 400400: f3 c3 repz retq
>>> 400402: 66 90 xchg %ax,%ax
>>> 00000000004004f0 <fred>:
>>> 4004f0: f3 c3 repz retq
>>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
>>> 4004f9: 00 00 00
>>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)
>>
>> Which means what? A failed attempt to bamboozle Bart?
>
> It means that different compilers (the above was GCC 4.8.3)
> do different things even between versions.

OK, up to the last 4.x.y gcc version, both functions generate only:

rep ret

for their bodies. That is, just two bytes of code. The rest of what you
posted above is just whatever garbage happened to follow.

From gcc 5.1 upwards, main includes code to zero eax before returning.

> GCC 9.3.0
>
> 0000000000400460 <fred>:
> 400460: c3 retq

I see it eventually dropped that 'rep' prefix.

> 400461: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
> 400468: 00 00 00
> 40046b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)

This is garbage.

> 0000000000400360 <main>:
> 400360: 31 c0 xor %eax,%eax
> 400362: c3 retq

> 400363: 90 nop

Other more garbage, or padding. In either case, these bytes are not
relevant to anything.

>
>
> But ultimately, nobody but you cares what code is generated
> in your contrived example.

Then you've missed the point of it, which is that compilers (at least
since version 5 in the case of gcc), ensure that main returns 0 if it
falls off the end of the function. But they don't anything do like that
anywhere else.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>Bart <bc@freeuk.com> writes:
>
>> On 07/09/2023 15:28, Ben Bacarisse wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>>> Do you have in mind examples of situations in which false positives
>>>> would cause problems, or even just irk the programmer?
>>> Well I'd be irked by having to write a 'return 0;' there just to shut
>>> the compiler up. But, to be clear, it's a tiny irk.
>>
>> Having to do so at the end of main() must have irked enough people that
>> most C compilers allow it to be left out.
>
>That seems unlikely but I don't know the reason.

I suspect historical inertia dating back to the early C compilers.

Given that on unix, the return value from main is made available
to the parent process via the wait/waitid/waitpid system calls,
programmers were generally good about putting a return statement
into the main() function regardless of whether the compiler warned
about it or not.

To that end, the recent gcc behavior of explicitly returning
zero when the return statement is missing is, in my mind, bogus,
as it potentially masks bugs and would indicate successful
completion regardless of the actually success/failure of the application.

That said, I always use -Wall -Werror when compiling with gcc.

Bart <bc@freeuk.com> writes:
>On 07/09/2023 17:15, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 07/09/2023 16:16, Scott Lurndal wrote:
>
>>>> When I compile that with gcc[-O2], I get:
>>>>
>>>> 0000000000400400 <main>:
>>>> 400400: f3 c3 repz retq
>>>> 400402: 66 90 xchg %ax,%ax
>>>> 00000000004004f0 <fred>:
>>>> 4004f0: f3 c3 repz retq
>>>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
>>>> 4004f9: 00 00 00
>>>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)
>>>
>>> Which means what? A failed attempt to bamboozle Bart?
>>
>> It means that different compilers (the above was GCC 4.8.3)
>> do different things even between versions.
>
>OK, up to the last 4.x.y gcc version, both functions generate only:
>
> rep ret
>
>for their bodies. That is, just two bytes of code. The rest of what you
>posted above is just whatever garbage happened to follow.

Correction. It is not "garbage". Those are some of the many
forms of NOP instructions generated to align the starting PC of the
next function.

Bart <bc@freeuk.com> writes:
>On 07/09/2023 17:15, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 07/09/2023 16:16, Scott Lurndal wrote:
>

>>
>> But ultimately, nobody but you cares what code is generated
>> in your contrived example.
>
>Then you've missed the point of it, which is that compilers (at least
>since version 5 in the case of gcc), ensure that main returns 0 if it
>falls off the end of the function. But they don't anything do like that
>anywhere else.

If there's a point at all there, it is that gcc is broken when it
generates an implicit return value of success (zero), in my opinion.

On 9/7/23 7:55 AM, Bart wrote:
> Why the special dispensation for main(), and not for user functions? And
> don't say because the Standard stipulates; it could have stipulated for
> user functions too!
>

As to many things, ancient history, which is WHY the Standard so stipulates.

main() is special, as it interfaces with the Operating System, which
started out a being Unix.

Returning 0 there was a "Successful" return, and was very common, so the
early compilers were designed to assume running off the end of main was
a successful completion.

For other functions, falling off the end was often because they didn't
have anything to return, so forcing the return of 0 would just be the
waste of an instruction, and for the size of machines back then, that
could be a significant cost.

Note, "void" hadn't been invented yet, so functions without a return
type were just implicitly considered to return an int (since that was
the cheapest), and normally the omition of the type was a signal that it
didn't actually return anything (but some code used the DEFINED behavior
of it being considered int). ANSI C89/ISO C90 continued this behavior,
and ISO C99 removed the implicit int, as it was decided that programs
using it were simple to fix, and really should be fixed.

Making falling of the end of a non-void function is a lot harder to fix,
as reliably detecting that this is actually being done can be hard, and
for some return types, forcing a return value expensive (and unclear
what it should be), thus this hasn't been made an error.

Most implementations can be made to give a warning on this (or even put
into a non-conforming mode to reject it) so the cost to programmers for
allowing it isn't that high (C is built on the assumption that
programmers know what they are doing and know how to use their tools).

With the C11 _Noreturn and C23 [[noreturn]] attributes, it is possible
to now come up with rules to allow detecting most of the cases where the
fall thorough can't happen, so perhaps it could be revisited, and see if
the advantages out weigh the breakage, but that isn't clear cut.

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

> On Wednesday, 6 September 2023 at 20:59:13 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>>
>> > On Wednesday, 6 September 2023 at 04:29:22 UTC+1, Ben Bacarisse wrote:
>> >> Bart <b...@freeuk.com> writes:
>> >> >
>> >> >
>> >> > This is just wordplay isn't it?
>> >>
>> >> Not from my side, no. I want to illustrate how I think about programs
>> >> and programming languages. To me, programs are texts to which we may be
>> >> able to ascribe a meaning. This text:
>> >>
>> > To me, a program is a "functional device". I see why you think it is a "text"
>> > and it has some non-superficialities to a text.
>> I am curious as to how you are so sure that you can see why I think it
>> is a text. I have a suspicion (from the way you reject my point of view
>> with almost no consideration) that you /don't/ see why I think it.
>>
>> Can you say why I think it a text? You may be right, but if not it's
>> going to be hard to have a reasonable discussion.
>>
> A C script is indistinguishable from text to any program which is not
> a C compiler (strictly, a C parser). The symbols are what is important,
> not the physical substrate. And a human can read the program and say
> what it means. So it's a text.
>
> That's probably a summary of your position. But I can't actually speak
> for you, of course.

I'm not sure if that's my position. It's not something I'd write to
explain what I mean. The first sentence in particular is baffling me.

Anyway, there is no need for you to know what I mean (unless you
particularly want to know).

>> > A C program is a functional device and the function is defined by the
>> > compiler we run it through. Or in this case, the compiler plus the
>> > flags to that compiler.
>> I've come across this opinion before. I can't take it seriously. The
>> effect is that the same text denotes wildly different "functional
>> devices". The code I posted (with an int-valued function that consisted
>> of a call to exit(...)) is a non-device when given to a compiler like
>> Bart's compiler (since it won't compile it) and yet works exactly as
>> intended when given to gcc. What's more, its actions -- when they are
>> permitted to exit at all -- are fully determined by what the language
>> standard says about the text but, according to you, that is not
>> sufficient. Without the compiler, there is no meaning.
>>
> It's a device that needs other devices to function correctly.

But, I would say, one only knows what "function correctly" means because
one knows the meaning of the text. Here's a C program running through a
compiler I have just written:

$ cat test.c
#include <stdio.h>

int main(void) {
printf("%g\n", 12e3);
} $ bcc test.c
$ ./a.out
3

Is it functioning correctly? How can you tell?

>> Will you indulge in a thought experiment? For a long while after the
>> publication of the Revised Report on the Algorithmic Language ALGOL 68,
>> there were no compilers for Algol 68. Did that mean the Algol 68
>> programs had no meaning? Or were their meanings pending and tentative,
>> based on the assumed appearance of compilers that "did the right thing"?
>> If so, why not always do that -- why not always say that the meaning is
>> defined by the report because that's the meaning a compiler should give
>> it?
>>
> OK. So first case. We have "Hello world" in Algol 68. But no Algol 68
> compiler is in existence. So we cannot say that "the meaning of this
> program is defined by the compiler". However it seems a bit of a
> stretch to say, "this program has no meaning".

I am glad you agree. I'd say it's way more than a stretch to say that.
It's is patently absurd to say that since the programmer wrote

BEGIN
print(("Hello world", new line))
END

knowing the computation that that text is supposed to represent. And
the compiler authors will be working hard to give that text exactly that
meaning.

> Anyone, probably anyone
> with a bit of programming experience but no Algol 68 knowledge, can
> see that it is "Hello world". So on the basis of case one, let's say
> that programs have a meaning, and that is defiend by the standards
> documents.

OK.

> Now let's consider case 2. Bart builds a "Bartlang to Algol 68
> compiler". A non- trivial program in Bartlang is run through it, and
> Algol 68 results. But humans can't understand this output. It might
> have hundreds of levels of intricately nested parentheses. So, given
> the Algol 68 and the Algol 68 specification, it's impossible to say
> what this program means.

Hard is not impossible. But that's incidental because I see now that
you have misinterpreted my meaning. A program text has a meaning
derived from the rules of the language even if no human can grasp it.

Given that this is case 2 of the thought experiment, you need to explain
how the Bartlang to Algol 68 compiler was written. Did the author just
make up the meaning of the Algol 68 text that the compiler produces, or
was the generation of the text driven by understanding what the
generated text (piece by piece at least) means?

> Given the Bartlang and the Bartlang manual,
> it is possible to say what the program means, as long as we accept
> that the Bartlang to Algol 68 compiler is bug free. But not given the
> Algol 68. Can we therefore say that the Algol 68 is not an Algol 68
> program? Of course not.

No one has ever suggested such a thing.

> And can we say "it has no meaning?". Depends
> how we use the word. Can we say that the Algol 68 is a "functional
> device" which, when fed to an Algol 68 compiler, will produce an
> executable which does something useful? Certainly.

So what? You are not (yet) addressing the question you remembered to
ask "has it a meaning"? And you don't know that it ever will do
anything at all, let along something useful as there may never be a
compiler that can handle it.

> It is a functional device, no dispute. The fact that we don't
> actually have the Algol 68 compiler doesn't change that.

It's your term, so how can I dispute it? All know is that

"A [..] program is a functional device and the function is defined by
the compiler we run it through."

so in case 2 we have a "functional device" with no defined function.
Seems odd to call it functional but as I say, it's your term.
But you don't seem to have answered the questions, the first being the
key one. I asked:

|| For a long while after the publication of the Revised Report on the
|| Algorithmic Language ALGOL 68, there were no compilers for Algol
|| 68. Did that mean the Algol 68 programs had no meaning? Or were their
|| meanings pending and tentative, based on the assumed appearance of
|| compilers that "did the right thing"? If so, why not always do that
|| -- why not always say that the meaning is defined by the report
|| because that's the meaning a compiler should give it?

Does the program in case 2 have no meaning? You have stated (and I
can't dispute) that it is something you call a "functional device", but
you've also said it has no defined function, so does that mean it has no
meaning?

> (Clearly there must have been some point in history when there were
> Philps screws but no screwdrivers, or Philips screwdrivers but no
> screws. But they were still devices.)

Sneaky change of focus to simply "a device"! Are they "functional
devices" on their own? Not according to you:

"It's a device that needs other devices to function correctly. A
Philips screwdriver is entirely useless without the special screws."

Now I suppose (since I think you are just seeing if these idea fly) you
can claim that "functional" and "function correctly" are different. Is
that going to be the game?

But if that is the case, you still have to address the question of what
correctly means for an Algol 68 program. Could it be that "function
correctly" means that the behaviour is one of those permitted by the
meaning of the source text?

--
Ben.

On 07/09/2023 18:25, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/09/2023 17:15, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 07/09/2023 16:16, Scott Lurndal wrote:
>>
>
>>>
>>> But ultimately, nobody but you cares what code is generated
>>> in your contrived example.
>>
>> Then you've missed the point of it, which is that compilers (at least
>> since version 5 in the case of gcc), ensure that main returns 0 if it
>> falls off the end of the function. But they don't anything do like that
>> anywhere else.
>
> If there's a point at all there, it is that gcc is broken when it
> generates an implicit return value of success (zero), in my opinion.

Well, it's good that you have a bold opinion. But I don't think it will
be popular, and is unlikely to be practical.

It means a program like hello.c from K&R2 will probably return a failure
code.

If I remove the zeroing from the code gcc produces for 'hello.c', then
it does in fact fail. (The failure code is likely to be the number of
characters output.)

Further, I can't get gcc to warn me about reaching the end of 'main'
without a suitable return or exit call, as it does for all other functions.

On 07/09/2023 18:24, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/09/2023 17:15, Scott Lurndal wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> On 07/09/2023 16:16, Scott Lurndal wrote:
>>
>>>>> When I compile that with gcc[-O2], I get:
>>>>>
>>>>> 0000000000400400 <main>:
>>>>> 400400: f3 c3 repz retq
>>>>> 400402: 66 90 xchg %ax,%ax
>>>>> 00000000004004f0 <fred>:
>>>>> 4004f0: f3 c3 repz retq
>>>>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
>>>>> 4004f9: 00 00 00
>>>>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)
>>>>
>>>> Which means what? A failed attempt to bamboozle Bart?
>>>
>>> It means that different compilers (the above was GCC 4.8.3)
>>> do different things even between versions.
>>
>> OK, up to the last 4.x.y gcc version, both functions generate only:
>>
>> rep ret
>>
>> for their bodies. That is, just two bytes of code. The rest of what you
>> posted above is just whatever garbage happened to follow.
>
> Correction. It is not "garbage".

But it's not part of preceding function's body, and it is wrong to show
them as such or to try to diassemble them.

> Those are some of the many
> forms of NOP instructions generated to align the starting PC of the
> next function.

I assume it is considered more efficient, in that part of a cpu which
speculatively decodes future instructions, to have fewer longer
instructions, rather than multiple single byte ones.

But it is still confusing to present them, especially given the missing
bytes in addresses 400404 to 4004ef.

It's also not clear why main has its next function starting at an
address which is a multiple of 4 (?), but both main and fred start at a
multiple of 16.

Bart <bc@freeuk.com> writes:
>On 07/09/2023 18:25, Scott Lurndal wrote:
> > Bart <bc@freeuk.com> writes:
> >> On 07/09/2023 17:15, Scott Lurndal wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>>> On 07/09/2023 16:16, Scott Lurndal wrote:
> >>
> >
> >>>
> >>> But ultimately, nobody but you cares what code is generated
> >>> in your contrived example.
> >>
> >> Then you've missed the point of it, which is that compilers (at least
> >> since version 5 in the case of gcc), ensure that main returns 0 if it
> >> falls off the end of the function. But they don't anything do like that
> >> anywhere else.
> >
> > If there's a point at all there, it is that gcc is broken when it
> > generates an implicit return value of success (zero), in my opinion.
>
>Well, it's good that you have a bold opinion. But I don't think it will
>be popular, and is unlikely to be practical.
>
>It means a program like hello.c from K&R2 will probably return a failure
>code.
>
>If I remove the zeroing from the code gcc produces for 'hello.c', then
>it does in fact fail. (The failure code is likely to be the number of
>characters output.)

Which, for that program, may be exactly what the programmer
intended. The number of characters output is an interesting
datum which a shell script could potentially make use of.

While the exit value can be treated as a success/failure
indication, it can also be used to pass arbitrary
integer data to the parent process (which isn't necessarily
a shell process).

Now I agree that an explicit return is better than relying on
the compiler to treat UB in any particular fashion.

And -Wall -Werror will fail to compile that code.

$ cc -Wall -Werror -o /tmp/x /tmp/xx.c
/tmp/xx.c: In function 'fred':
/tmp/xx.c:1:4: error: control reaches end of non-void function [-Werror=return-type]
int fred(void) {}
^
/tmp/xx.c: In function 'main':
/tmp/xx.c:2:4: error: control reaches end of non-void function [-Werror=return-type]
int main(void) {}
^
cc1: all warnings being treated as errors

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 7 September 2023 at 07:10:49 UTC+1, Kaz Kylheku wrote:
>> I'm quite puzzled by your angle which seems to be that if the
>> reachability diagnostic cannot be done accurately, due to theory,
>> translation units and run-time conditions/inputs, then it's
>> a bad diagnostic not worth doing (or at least not worth having
>> right in the language). Pardon me if I'm misconstruing antyhing.
>>
> Take this one.
>
> int gamemainloop(void)
> {
> if (allocatememorybuffers() == -1)
> return -1; // out of memory;
> if (hardwaretest() == FAIL)
> return -2; // proper hardware not installed
> loopforever(); // update / render loop, never returns
> }
>
> Obviously to prove that loopforever loops forever we need to examine it.

No, just declare it as:
_Noreturn void loopforever(void);
in C11 and later, or
[[noreturn]] void loopforever(void);
in C23.

Currently the only effect of _Noreturn is that the behavior is undefined
if the function returns, but if a future C added rules to require return
statements in non-void functions, noreturn functions could easily be
part of the analysis.

> And even if we could, its the halting problem - most real programs
> written by humans can be trivially proven to either halt or run
> forever, but it's hard to write that requirement into a programming
> language.

Nobody is suggesting that a C compiler must include a general halt
decider.

C#, in my opinion, has a reasonable set of rules for this.

[...]

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

Bart <bc@freeuk.com> writes:
>On 07/09/2023 18:24, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 07/09/2023 17:15, Scott Lurndal wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 07/09/2023 16:16, Scott Lurndal wrote:
>>>
>>>>>> When I compile that with gcc[-O2], I get:
>>>>>>
>>>>>> 0000000000400400 <main>:
>>>>>> 400400: f3 c3 repz retq
>>>>>> 400402: 66 90 xchg %ax,%ax
>>>>>> 00000000004004f0 <fred>:
>>>>>> 4004f0: f3 c3 repz retq
>>>>>> 4004f2: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
>>>>>> 4004f9: 00 00 00
>>>>>> 4004fc: 0f 1f 40 00 nopl 0x0(%rax)
>>>>>
>>>>> Which means what? A failed attempt to bamboozle Bart?
>>>>
>>>> It means that different compilers (the above was GCC 4.8.3)
>>>> do different things even between versions.
>>>
>>> OK, up to the last 4.x.y gcc version, both functions generate only:
>>>
>>> rep ret
>>>
>>> for their bodies. That is, just two bytes of code. The rest of what you
>>> posted above is just whatever garbage happened to follow.
>>
>> Correction. It is not "garbage".
>
>But it's not part of preceding function's body, and it is wrong to show
>them as such or to try to diassemble them.
>
>> Those are some of the many
>> forms of NOP instructions generated to align the starting PC of the
>> next function.
>
>I assume it is considered more efficient, in that part of a cpu which
>speculatively decodes future instructions, to have fewer longer
>instructions, rather than multiple single byte ones.
>
>But it is still confusing to present them, especially given the missing
>bytes in addresses 400404 to 4004ef.

They're missing because the intervening CRT functionality wasn't
relevent and I elided it when posting.

>
>It's also not clear why main has its next function starting at an
>address which is a multiple of 4 (?), but both main and fred start at a
>multiple of 16.

See comment immediately above.

As it happens, the function after main wasn't written in C, it's
the ELF entry point.

0000000000400404 <_start>:
400404: 31 ed xor %ebp,%ebp
400406: 49 89 d1 mov %rdx,%r9
400409: 5e pop %rsi
40040a: 48 89 e2 mov %rsp,%rdx
40040d: 48 83 e4 f0 and $0xfffffffffffffff0,%rsp
400411: 50 push %rax
400412: 54 push %rsp
400413: 49 c7 c0 70 05 40 00 mov $0x400570,%r8
40041a: 48 c7 c1 00 05 40 00 mov $0x400500,%rcx
400421: 48 c7 c7 00 04 40 00 mov $0x400400,%rdi
400428: e8 b3 ff ff ff callq 4003e0 <__libc_start_main@plt>
40042d: f4 hlt
40042e: 66 90 xchg %ax,%ax

Bart <bc@freeuk.com> writes:
[...]
> I've already suggested a compiler should return all-zeros as a default
> return value for code that runs into the final '}'. That will provide
> a consistent return value.

That could mask bugs.

int func(void) {
if (this) {
return a_value;
}
else if (that) {
return another_value;
}
else if (the_other) {
return yet_another_value;
}
}

Perhaps I simply forgot to write a return statement at the end, either
before the closing } or in an else clause. Currently, a compiler is not
required to diagnose this, but many will warn about it with the right
options. If the language stated that falling off the end implicitly
returns "all-zeros" (I won't get into what that means), then the behavior
is well defined and the compiler is unlikely to be able to help.

--
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:
> David Brown <david.brown@hesbynett.no> writes:
>> With C11, you can write :
>>
>> _Noreturn void abort_with_error_message(const char *);
>>
>> So you don't have to wait until C23 (unless you really want the attribute
>> syntax).
>
> I somehow missed that in C11. Thanks.

C11 added the _Noreturn keyword and the <stdnoreturn.h> header, which
defines a macro `noreturn` that expands to `_Noreturn`.

C23 makes all that obsolescent, and introduces attributes, including
[[noreturn]].

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