On 9/6/2023 12:51 PM, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 06/09/2023 18:37, Malcolm McLean wrote:
>>> On Wednesday, 6 September 2023 at 16:35:57 UTC+1, David Brown wrote:
>
>>> RISC processors often have "jump and link" rather than "call".
>>
>> Link and jump.
>>
>
> ARM calls it branch and link (BL). Horses for Courses.
>

For some reason I am now thinking about the branch delay slot over in
SPARC. Never put a MEMBAR instruction in a branch delay slot!!!!!!!!!

Malcolm McLean <malcolm.arthur.mclean@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 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.

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?

> Does the program mean anything? Well yes, the identifier getversion()
> conveys a meaning to the human reader.

To be honest, my first reaction was that this is just a wind. The only
concession to the notion that the program text means anything at all is
that the names might convey something to the reader.

>> > I'm struggling to reconcile this behaviour, with your statement that 'C
>> > does not allow any such thing'.
>>
>> gcc's inventions of code from meaningless C texts in not "C allowing it"
>> it's gcc making something up.
>>
>> > Well SOMETHING is allowing it! But you're going to argue that:
>>
>> No, something (the compiler) is doing what you describe. That's not
>> "allowing" it. Allowing is a legalistic term.
>>
> The term is accepting or rejecting the input.

Eh? That's not the term Bart used. I wanted to say what I thought was
wrong about the terms actually being used. By introducing yet another
term, while suggesting it's what was meant all along ("the term is...",
rather than "we might use the term...") you just muddy the waters.

--
Ben.

On 06/09/2023 20:17, David Brown wrote:
> On 06/09/2023 19:13, Bart wrote:

>> So something is expected on the virtual stack. If that return
>> statement is commented out, it generates:
>>
>>    getversion:
>>       retfn
>
> There's your problem.  That will almost certainly be invalid (unless you
> have a very odd ABI, or more steps in your code generation sequence to
> add a "push").  But that's all a problem with your code generator, not
> with the way C is defined.

It highlights that the problem is deeper than it looks. There is
something malformed about the function, since at the common return
point, some paths to that point won't have a pushed return value.

It's similar to trying to do this in C:

x = (a ? b);
x = (a ? b :)

When a is false, what do you store in x? Surely you wouldn't use any old
rubbish that was lying around. But here, the type system would object
even if the malformed syntax could be sorted. That is the approach I use.

> The returned value is always returned in the register "return_reg".

But I've a chosen a stack-based IR (register- or temp-based IRs are
harder to work with).

> An alternative method is to create a local variable called
> "return_value" at the entry to any non-void function.  Then your IRs
> become :
>
>     getversion :
>         local return_value (char *)
>         assign return_value, "0.99"
>         ret
>
> and
>
>     getversion :
>         local return_value (char *)
>         ret
>
> The return value slot is always created and returned in the same way.
> But in the second case, nothing is assigned to it.

Yes, this can work; you just have the extra headache of removing those
extraneous loads and stores.

(On actual stack-based bytecode for a dynamic language, I reserve a
zeroed stack slot for a return value. This allows functions to be called
via references, without knowing if they are functions or procedures. A
return value is always available in either case.

With static code you don't expect to do that.)

Although this can still leave the return value undefined even if the
mechanism is sorted. You might say, you can do this anyway:

int x;
return x;

But unitialised locals is a different subject.

Bart <bc@freeuk.com> writes:

> On 06/09/2023 04:29, Ben Bacarisse wrote:
>> Bart <bc@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:
>> int main(void) { return 1; }
>> has a meaning if we interpret it as C. That's an important step,
>> because this program
>> int main(void) { return 1; };
>> is meaningless if we interpret it as C, but if we interpret it as GNU C,
>> then it /does/ have a well-defined meaning (as it happens, the same
>> meaning as the first).
>
> I assume GNU C allows semicolons after function definitions. That's
> unfortunate. If the grammar rule was applied strictly, then there would be
> no programs in existence that would use semicolons like that.

K&R C allowed it, mainly because a type-specifier can be omitted and
defaults to int. The /grammar/ in K&R does not permit it, but the text
says that, if the type-specifier is missing it is taken to be int.

A lot of early C was like that: a very simple grammar (presumably to
keep the compiler small enough to run) with some rules that override or
refine it.

And then C got popular and compilers were stuck with it or risked
rejecting code for something that, frankly, is not important.

> Instead, some programs will have semicolons, so one that normally compiles
> happily, is at risk of failing when a different compiler and/or different
> set of options is used. And for what benefit?

The main benefit is to existing programs. A language with lots of users
can't easily make breaking changes. And if a compiler does, in a
open-source world, a fork will appear to satisfy the demand.

>
>
>> This text:
>> int main(void) { int a[] = {1}; return a[2]; }
>> is meaningless (as C). It does not "do" anything because it means
>> nothing.
>
> I assume you mean because it accesses out-of-bounds elements of 'a'.
>
> I would not call that meaningless, it is a valid C program with undefined
> behaviour. It is not interestingly different from one using 'return a[f()]'
> where f() is some external function.

Well it is to me (though it depends if the text of the external function
is also available).

A program this is, from inspection, undefined is different to one that
may be undefined when run. The canonical example being one that uses
input so that no static analysis could detect the undefined nature.

> But a compiler could choose to point out an out-of-bounds access; I'm
> surprised that gcc -Wall -Wextra -Wpedantic doesn't do so.

It does -O2. That's quiet common with gcc as the optimiser does much
more detailed static analysis.

And if you compile with -fsanitize=undefined, even with no optimisation
you get this when you run the compiled program:

ub.c:1:41: runtime error: index 2 out of bounds for type 'int [1]'
ub.c:1:41: runtime error: load of address 0x7ffce05a9a8c with
insufficient space for an object of type 'int'

That's permitted /because/ the code is undefined. If the meaning were
defined operationally (as I think is your preference) the compiled code
should just access the int at a+2 and set the program's status
accordingly.

>
>>> char* getversion(void) {}
>>>
>>> int main(void) {
>>> puts(getversion());
>>> }
>>>
>>> So, I can compile this using:
>>>
>>> gcc -std=c99 -Wall -Wpedantic prog.c
>>>
>>> which produces an executable that either crashes or prints nonsense. And
>>> that's OK, because it is undefined?
>> No, what happens is OK because you asked gcc to guess a meaning for this
>> meaningless text. You can ask gcc not to (at least in this case) by
>> saying
>> gcc -Werror -std=c99 -Wall -Wpedantic prog.c
>
> Which is OK for this tiny program. But in practice such things are buried
> in 10s or 100s of thousands of lines, and using such options means it is
> has to be utterly perfect in terms of not upsetting the compiler.

Yes. You really need to keep a note of the warnings you want and the
ones you dont't, along with which ones should be errors. Of course you
don't need to that with your own compiler, because you already did is as
you were writing it. It will treast as errors excatly those things you
consider serious, warn about those things you like to know abut and
ignore everything else.

> Then it's a choice between writing a working, bug-free program that does
> what it's meant to do, or expending too much effort dotting every I and
> crossing every T to satisfy the compiler on a thousand inconsequential
> details.

It's better to either keep a set of options you like. But you can also
just fix as you go. Most i dotting and t crossing is trivial.

> A compiler like the one invoked by gcc doesn't understand that some things
> might be more important than others. For example:
>
> Extra semicolon Warning
> Incompatible pointers Warning
> (without using a cast)
> Unused local or parameter Warning
> Unused label Warning
> Cast T* direct to func ptr Warning
> (instead of casting via an int)
>
> Which one of these could have a serious affect on behaviour? Assume that a
> programmer using a cast has the matter in hand.
>
> I would say incompatible pointers is what is worth failing a program
> for. That can easily be circumvented by using a cast, /if/ it was
> intentional and not inadvertent.

gcc allows you to do that. Some people use C like a portable assemler,
so they really don't want to put in something which, on their hardware,
is a no-op. I can't honestly say I don't want gcc to cater to that
style of programming. I don't what people like coding my pacemaker, but
gcc does allow much stricter checks to be used.

> However I would also fail the extra semicolon, since it is utterly trivial
> to fix, and bestows no advantages in allowing it. (If you say
> machine-generated code, then you really need to fix that generator.)

Your choice.

> Those other three are harder to do something about. The unused names might
> be temporary situations, so you might want to turn on those checks
> separately, but not in a routine build.
>
> The object to function pointer casts I think is a flaw in the language,
> given that you can convert between object pointers and ints, and between
> ints and function pointers, allowing you to do indirectly it that way.

You can ask for it with or with a cast as well. The route via an
integer type is just a way to prevent most compilers from saying
anything. None of these different methods will work on all systems, but
if you know it's safe, you can (with gcc) just not ask for the warning
and do it drectly.

I don't know what aspect you consider to be a flaw in the language. The
language says you can't do it directly without a diagnostic, and that if
you go round the houses via an interer type (where it won't always to be
possible to tell where the pointer originally came from) it's up to the
implementation what happens.

> So the objection is silly.

The object is a warning that the code is not portable. C makes are
distinction between object and function pointers because some machines
make that distinction very strictly.

>>> Even the compilation reported that it
>>> ran into the end of a non-void function.
>> Yes, and you /still/ went ahead and ran the code the compiler invented
>> from the meaningless C text.
>
> You could run it like this 'gcc .... prog.c && a'.

You could. So what? It's still running the code without looking at
what the compiler said about it.

> Or you or someone else can later run that program without being aware of
> the warning that was generated, or having forgotten.

Yes, just like any buggy code. The bug has the advantage that is was
identified at compile time but no one wanted to pay attention. That's
low on my list of things to worry about in the world.

You get really worked up about the warning/error distinction in gcc, but
there is never any substitute for paying attention. Making a lot of bad
things are errors made into errors might encourage more people to ignore
the warings that are left. There's an argument for never making
anything a hard error so as to encourage every warning to be properly
onsidered before moving on.

>>> * That was not a C compiler
>> You are mixing up different remarks. gcc (on it's own) is not a C
>> compiler. gcc -std=c99 -Wall -Wpedantic is a C compiler.
>
> I don't know about that:
>
> c:\c>gcc -Wall -Wpedantic -Werror -Wextra -std=c99 hello.ftn
> gcc: error: hello.ftn: Fortran compiler not installed on this system

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
[...]
>> I assume GNU C allows semicolons after function definitions. That's
>> unfortunate. If the grammar rule was applied strictly, then there would be
>> no programs in existence that would use semicolons like that.

Just to be clear, a semicolon after a function definition:

void foo(void) {};

isn't associated with the function definition. The semicolon is treated
as a file-scope declaration. If the above is valid, then so is a
source file consisting of a single line with just a semicolon.

> K&R C allowed it, mainly because a type-specifier can be omitted and
> defaults to int. The /grammar/ in K&R does not permit it, but the text
> says that, if the type-specifier is missing it is taken to be int.
[...]

So K&R C (and C90?) treated this:

;

at file scope as a definition with an implicit type of int, so it's
equivalent to this:

int;

I *think* that's either a constraint violation or a syntax error in C90
and later, but I haven't absorbed the syntax for "declaration" and
"declarator" well enough to be sure of that.

gcc warns about `int;` by default, and rejects it with the options
"-std=c90 -pedantic-errors". The diagnostic is "useless type name in
empty declaration". The diagnostic for a lone semicolon with the same
options is "ISO C does not allow extra ‘;’ outside of a function
[-Wpedantic]".

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

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

> David Brown <david.brown@hesbynett.no> writes:
>>On 06/09/2023 18:37, Malcolm McLean wrote:
>>> On Wednesday, 6 September 2023 at 16:35:57 UTC+1, David Brown wrote:
>
>>> RISC processors often have "jump and link" rather than "call".
>>
>>Link and jump.
>>
>
> ARM calls it branch and link (BL). Horses for Courses.

I think it goes back to the IBM System/360. That had branch and link
(and branch and link register) instructions for function calling.

--
Ben.

Richard Damon <Richard@Damon-Family.org> writes:

> On 9/4/23 6:38 PM, vallor wrote:
>
>> On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in
>> <ucvuhq$gmlg$1@dont-email.me>:
>>
>>> 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?
>>
>> Isn't asking a C compiler to watch for interminable loops and
>> such things akin to trying to solve the halting problem?
>>
>> I mean, I'm not the smartest person in the room by far, but even
>> I know that this is, perhaps, a bit far-out...
>>
>> ...or is it? I could be mistaken.
>
> I think the proposal to have it look to see if something might
> happen was limited to evaluating CONSTANT values.
>
> I seem to remember that a loop with a non-constant-expression
> control expression allowed the complier to assume the loop will
> eventually end, and thus if the loop had no observable effects,
> could be optimized away, even if it turns out that the condition
> could never be met.
>
> Thus, it doesn't become a Halting Problem analysis, as loop
> termination becomes "correctly" predicted syntactic means.

You're right that what the C standard says about while() and
for() loops is only for constant control expressions (along with
some other criteria, all of which are easily staticly checkable),
and so is not a halting problem problem.

I have the sense though that what is being asked about is whether
arbitrary code in a function body might reach the closing brace
without having done a return, which is equivalent to the halting
problem.

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Bart <bc@freeuk.com> writes:
> [...]
>>> I assume GNU C allows semicolons after function definitions. That's
>>> unfortunate. If the grammar rule was applied strictly, then there would be
>>> no programs in existence that would use semicolons like that.
>
> Just to be clear, a semicolon after a function definition:
>
> void foo(void) {};
>
> isn't associated with the function definition. The semicolon is treated
> as a file-scope declaration. If the above is valid, then so is a
> source file consisting of a single line with just a semicolon.
>
>> K&R C allowed it, mainly because a type-specifier can be omitted and
>> defaults to int. The /grammar/ in K&R does not permit it, but the text
>> says that, if the type-specifier is missing it is taken to be int.
> [...]
>
> So K&R C (and C90?) treated this:

Not C90 as far as I know.

> ;
>
> at file scope as a definition with an implicit type of int, so it's
> equivalent to this:
>
> int;

Probably, though it's hard to tell if that is "equivalent" since there
are no observable facts. A K&R C Unix V7 compiler running on a PDP11
simulator accepts this code silently:

;
int;
int main(){ return 1; };

K&R1 says that both the type specifier and the storage class specifier
can be omitted, and that int is assumed when no type is given. When the
storage class is missing it is assumed to be auto in a function and
extern outside, with the exception that function are never automatic.

> I *think* that's either a constraint violation or a syntax error in C90
> and later, but I haven't absorbed the syntax for "declaration" and
> "declarator" well enough to be sure of that.

The syntax is not always enough, at least for very early C. K&R syntax
explicitly rules out all the cases above, but the text then adds
(overrides?) the syntax. I don't know of there are cases where the text
in C90 overrides the syntax.

> gcc warns about `int;` by default, and rejects it with the options
> "-std=c90 -pedantic-errors". The diagnostic is "useless type name in
> empty declaration". The diagnostic for a lone semicolon with the same
> options is "ISO C does not allow extra ‘;’ outside of a function
> [-Wpedantic]".

All good on an old K&R compiler! You really had to know what you were
doing in those days.

--
Ben.

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

> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 06/09/2023 18:37, Malcolm McLean wrote:
>>>
>>>> On Wednesday, 6 September 2023 at 16:35:57 UTC+1, David Brown wrote:
>>>>
>>>> RISC processors often have "jump and link" rather than "call".
>>>
>>> Link and jump.
>>
>> ARM calls it branch and link (BL). Horses for Courses.
>
> I think it goes back to the IBM System/360. That had branch and link
> (and branch and link register) instructions for function calling.

I had to think for a moment before remembering that on
the System/360 it was BAL and BALR.

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bart <bc@freeuk.com> writes:
>
> [...]
>
>>> I assume GNU C allows semicolons after function definitions. That's
>>> unfortunate. If the grammar rule was applied strictly, then there would be
>>> no programs in existence that would use semicolons like that.
>
> Just to be clear, a semicolon after a function definition:
>
> void foo(void) {};
>
> isn't associated with the function definition. The semicolon is treated
> as a file-scope declaration. If the above is valid, then so is a
> source file consisting of a single line with just a semicolon.
>
>> K&R C allowed it, mainly because a type-specifier can be omitted and
>> defaults to int. The /grammar/ in K&R does not permit it, but the text
>> says that, if the type-specifier is missing it is taken to be int.
>
> [...]
>
> So K&R C (and C90?) treated this:
>
> ;
>
> at file scope as a definition with an implicit type of int, so it's
> equivalent to this:
>
> int;
>
> I *think* that's either a constraint violation or a syntax error in C90
> and later, but I haven't absorbed the syntax for "declaration" and
> "declarator" well enough to be sure of that.

In ISO C (including C90), a semicolon by itself (and outside of
any function) has no derivation under the grammar. It's not a
declaration or anything else.

In ISO C (including C90), a declaration 'int;' is a constraint
violation.

(The foregoing presumes my cursory checking of the standards is
correct.)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Bart <bc@freeuk.com> writes:
>> [...]
>>>> I assume GNU C allows semicolons after function definitions. That's
>>>> unfortunate. If the grammar rule was applied strictly, then there would be
>>>> no programs in existence that would use semicolons like that.
>>
>> Just to be clear, a semicolon after a function definition:
>>
>> void foo(void) {};
>>
>> isn't associated with the function definition. The semicolon is treated
>> as a file-scope declaration. If the above is valid, then so is a
>> source file consisting of a single line with just a semicolon.
>>
>>> K&R C allowed it, mainly because a type-specifier can be omitted and
>>> defaults to int. The /grammar/ in K&R does not permit it, but the text
>>> says that, if the type-specifier is missing it is taken to be int.
>> [...]
>>
>> So K&R C (and C90?) treated this:
>
> Not C90 as far as I know.

You're right.

>> ;
>>
>> at file scope as a definition with an implicit type of int, so it's
>> equivalent to this:
>>
>> int;
>
> Probably, though it's hard to tell if that is "equivalent" since there
> are no observable facts. A K&R C Unix V7 compiler running on a PDP11
> simulator accepts this code silently:
>
> ;
> int;
> int main(){ return 1; };
>
> K&R1 says that both the type specifier and the storage class specifier
> can be omitted, and that int is assumed when no type is given. When the
> storage class is missing it is assumed to be auto in a function and
> extern outside, with the exception that function are never automatic.

Right. What I was wondering about is which rule makes
int;
at file scope invalid -- and I think I've found the answer.

C90 6.5 has this syntax:
declaration
declaration-specifiers init-declarator-list[opt] ;
with this constraint:
A declaration shall declare at least a declarator, a tag, or the
members of an enumeration.
The wording in later editions is similar. K&R1 did not have that
constraint.

So `int;` satisfies the syntax of a declaration, but violates the
constraint.

The *init-declarator-list* is optional so you can have declarations
like:
enum foo { x, y };
Both `enum foo { x, y }` and `int` are type specifiers; the former is
allowed by itself in a declaration, but the latter is not.

Getting back to the original issue, I think that gcc's acceptance of a
lone semicolon at file scope goes back to K&R C, which allowed it; the
old "implicit int" rule made it equivalent to `int;`, which was allowed
because the constraint I mentioned above had not yet been introduced.

It would IMHO have been reasonable for gcc to make this invalid by
default. Of course it rejects it if you ask for conformance.

--
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 Wednesday, 6 September 2023 at 19:49:24 UTC+1, David Brown wrote:
> On 06/09/2023 18:37, Malcolm McLean wrote:
> > On Wednesday, 6 September 2023 at 16:35:57 UTC+1, David Brown wrote:
> >> On 06/09/2023 16:53, Malcolm McLean wrote:
> >>> On Wednesday, 6 September 2023 at 15:08:56 UTC+1, David Brown wrote:
> >>>> Bart
> >>>
> >>>> I'd have been happy to see C defined in a way that makes it undefined
> >>>> behaviour if a non-void function reaches the terminating close brace. I
> >>>> would not have been happy to see it defined to require a "return expr"
> >>>> statement in non-void functions, because I think these things should be
> >>>> about the behaviour of functions, not their syntax. But I personally
> >>>> don't see the current standard rules here as a big issue, because they
> >>>> rule out misuse (you are not allowed to attempt to use the value of
> >>>> falling off the end of a non-void function), and they do not force
> >>>> programmers to write code that is never executed. It is all very simple
> >>>> and natural in terms of how functions and calls are typically implemented.
> >>>>
> >>> The way some other languages do it is to have a special variable which is
> >>> the return value. (Often it has the same name as the function). That variable
> >>> is the returned whne the function exits. So it's not possible to write a function
> >>> that returns nothing on some control paths.
> >> That's true. But it is still entirely possible to return nonsense.
> >> Some languages will choose to initialise the return variable to a
> >> default dummy value, making that a minimum return value. I've never
> >> been a fan of that idea - such defaults are often incorrect and invalid
> >> for the specification of the function, and I'd rather have compiler
> >> warnings about missing return values (just as I'd rather not have local
> >> variables be default initialised).
> >>
> >> No matter how a programming language defines these things, there are no
> >> general methods to guarantee that the function returns the correct value
> >> (or /a/ correct value, if there are several possibilities) according to
> >> its requirements. And if it is not going to return a correct value, why
> >> fuss about what it does or does not return - the code is buggy. The
> >> best a language and/or tool can do is tell you when you are likely,
> >> according to common practices, to have made a mistake. C compilers do
> >> that just as well as Pascal compilers do, or other languages that have a
> >> special return variable.
> >>>>
> >>>>
> >>>> Tool vendors know their audience and their needs - the needs of
> >>>> someone coding a little game on Windows, those of someone making a
> >>>> rocket engine controller, and those of someone maintaining 40 year old
> >>>> code are totally different.
> >>>>
> >>> Yes, but no-one wants "functions" which sometimes return a value and sometimes
> >>> don't.
> >> Really? Do you speak for all programmers here? Ben gave an example
> >> earlier of a function that has a non-void return type, but which will
> >> never return any value because it never returns.
> >>
> >> I'll accept that in almost all cases, you either want to be sure that a
> >> function returns the correct value, or that you have some way of knowing
> >> that you have a good return value. Many modern languages have natural
> >> support for that - a Python function might return a value or None, a C++
> >> function might return a std::optional<>, and other languages have ways
> >> of indicating success or failure. I think it is rare to find uses for
> >> functions where you might get a valid return, or might not, and have no
> >> clear way of determining the case.
> >>> In a little game no real harm can be done, whilst in a rocket engine
> >>> contoller an expensive rocket might blow up, but it's the same bug.
> >> People writing rocket engine controllers know how to to use their tools
> >> and high quality development processes - such bugs will never occur in
> >> their code, regardless of the language used.
> >>>>
> >>>>> Assuming it doesn't affect the mechanics of how function calls work in
> >>>>> the target. A stack-based target /must/ push some return value,
> >>>>> otherwise it'll interpret some wrong value as the return address.
> >>>>>
> >>>> I could only imagine this happing in a C implementation on a machine
> >>>> that has separate return and data stacks - I don't know any such
> >>>> systems, but they could hypothetically exist. The solution there would
> >>>> be to push a fake return value (perhaps all zeros, perhaps random).
> >>>>
> >>>> In more common single-stack systems, return values are either in
> >>>> registers, or in stack space allocated by the caller, not the callee.
> >>>>
> >>> There are two ways of doing it on a single stack-based system.
> >>> The first is to push the arguments in caller, then push a dummy value
> >>> for the return value, which is later filled in by the callee. The other way
> >>> is to push just the arguments, and make the callee push the return value.
> >> In theory, there are many ways these things can be done. In practice,
> >> there are very few that make sense on most processors. Your second
> >> method here is never used in reality. For general processors, return
> >> values are either in registers, or the caller allocates space on the
> >> stack before calling. A pointer to this space may be passed as a hidden
> >> parameter, or the callee may find it implicitly as a fixed offset from
> >> the stack pointer. (If the size is unknown, as might be the case in a
> >> dynamically typed language, the actual return value will be a fixed-size
> >> pointer or proxy object of some kind.) For some very small CISC
> >> microcontrollers, return values can be placed in specific fixed
> >> addresses in ram.
> >>
> >> It makes no sense for a function to push a return value, because then it
> >> could no longer use a "return" assembly instruction - you need the
> >> return address will be at the top of the stack. It would not be
> >> /impossible/ to dig the return address out the stack and do an indirect
> >> jump, but doing so would be extra complications, break C ABI's, and
> >> undermine the hardware accelerations and optimisations that modern
> >> processors have to make "return" instructions as fast as possible.
> >> (RISC processors generally have more flexibility for return addresses,
> >> but much of the same logic still applies - and it would make C ABI's
> >> more complicated.)
> >>
> > RISC processors often have "jump and link" rather than "call".
> Link and jump.
> > The stack
> > is purely conventional, it doesn't mean anything at the silicon level.
> That is true for some RISC processors, not for others. And even for
> those where a stack is not determined by the hardware, a stack is always
> in use in C implementations, and the choice of stack pointer register is
> fixed in the ABI.
> > "Jump and link" places the current program counter in a designated
> > register, then jumps to an address.
> Link and jump - yes, I know how it works.
> > So a leaf function can simply
> > "jump to link register" to return. A non-leaf function has to save the link
> > register on the stack and retrieve it.
> Correct.
> > Since caller doesn't know whether a function is leaf or not, in this case
> > the return address would have to be pushed by the callee.
> >
> In which case? What are you talking about?
>
> The caller never pushes the return address in RISC architectures with
> link-and-jump calling mechanics.
>
No, but if callee is not leaf, then unless you've got a weird and wonderful ABI,
the same register will be used for the link and jump to callee's subroutine.
So it has to be saved, then retrieved when callee returns.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-05, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>
>>>>> A Turing machine is completely defined and has no run-time
>>>>> inputs; everything is on the tape.
>>>>
>>>> This is wrong. A Turing machine is just the machine. The tape
>>>> is separate.
>>>
>>> Apologies for that. A term for what I'm referring to is
>>> "Turing machine configuration" (offered in _Introduction to the
>>> Theory of Computation_, 3rd ed, Michael Sipser).
>>
>> Not a term I'm familiar with. Seems like a poor choice
>> of phrase.
>
> It's quite widely used but not exactly as Kaz seems to be
> suggesting. Siper uses it in the way I've seen other authors use
> it:
>
> "As a Turing machine computes, changes occur in the current
> state, the current tape contents, and the current head location.
> A setting of these three items is called a configuration of the
> Turing machine."
>
> A TM configuration represents the state of a computation.

I see. That makes more sense. I still think the name is a
little funny, but at least I see the point of the concept.

>>>> It would be pointless to talk about "Turing machines"
>>>> if all a given "Turing machine" could do is one computation.
>>>
>>> "Does this Turing machine configuration halt?" is a
>>> meaningful question.
>>
>> The question usually asked is "Does a given Turing machine halt
>> when started on a blank tape?". Given a Turing machine T and
>> input tape I, it's easy to construct a Turing machine T' such
>> that T' halts when started on a blank tape if and only iff T
>> halts when started on I. ISTM that the notion of a Turing
>> machine configuration (whether by that name or a different one)
>> isn't very useful.
>
> True, but given the way it is actually defined it is very
> useful as a way to talk about the progress of a computation.
> [...]

Yes. Thank you for the clarification.

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.
>
> > 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. A Philips
screwdriver is entirely useless without the special screws. A normal
electrical screwdriver will break a reverse-thread screw. It's very common
for devices either not to function at all or to function differently if the
other devices they interact with are not set up in the way expected.
>
> 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". 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.

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. 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.
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.
It is a functional device, no dispute. The fact that we don't actually have the
Algol 68 compiler doesn't change that. (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.)
>
> > Does the program mean anything? Well yes, the identifier getversion()
> > conveys a meaning to the human reader.
> To be honest, my first reaction was that this is just a wind. The only
> concession to the notion that the program text means anything at all is
> that the names might convey something to the reader.
>
That's also a non-trival way in which programs might be thought of as texts.
They contain symbols which are meaningless to the compiler, but not to the
human reader.

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. Most C
programs are split into several translation units, with only one
being compiled at a time. I hope I don't have to explain that
any kind of whole-program diagnostic like this is a non-starter
given the C compilation model.

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

[lack of return statements in non-void functions]

> A future edition of the standard *could* require a diagnostic for
> a non-void function that can reach the closing } given certain
> assumptions. I've quoted the requirement from C# that does this
> and suggested that it could be adapted for C. [...]

The C# rule is not suitable for C because it would require
diagnostics for some strictly conforming programs, and no doubt
would break a fair amount of existing code even though that code
is not strictly conforming. In practical terms the C# rule is
not much different from saying return is always required. That's
not a good fit to the C language or its culture.

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.

Diagnostics that flag some correct programs are par for the course
in static checking. That's what you accept in order to find problems
without running the program.

For instance, this snippet requires diagnosis:

int x = 3;
char *cpx = &x;
int *ipx = cpx;
printf("%s\n", *cpx); // assumed to be declared properly

The rule of thub in C is that most pointer conversions are a code smell,
and so are diagnosed. The requirement for diagnosis is all which is
rendering the code incorrect; without it, it would be correct, as
would an edited version with casts put in.

That's a clear example of a diagnostic rule which is not accurate
(and we take it for granted that way, even like it).

No I can see that the bar has to be fairly high for making something a
required diagnostic in the international language standard, given that
implementors can already diagnose whatever they want.

The users who want diagnostics about ends of value-returning functions
being reached (and even stop the program in that situation) are getting
them from compilers.

However you look at it, there doesn't seem to be a pressing need to push
that into the language. Sure.

> Most C
> programs are split into several translation units, with only one
> being compiled at a time. I hope I don't have to explain that
> any kind of whole-program diagnostic like this is a non-starter
> given the C compilation model.

It's not just that, but run-time conditions:

if ((*gpio32_ptr & FOO_MASK) != 0)
return 42;
}

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.

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

Say under some simple rule requiring that that if reaching the end of a
function is conditional on the value of one or more expressions,
they must be constant expressions whose values prevent that.

What would be undesirable about working with that?

Say that mountains of legacy code aren't an issue. (Or that they
are, but what else?)

--
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 2023-09-07, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> The C# rule is not suitable for C because it would require
> diagnostics for some strictly conforming programs, and no doubt
> would break a fair amount of existing code even though that code
> is not strictly conforming. In practical terms the C# rule is
> not much different from saying return is always required. That's
> not a good fit to the C language or its culture.

I'm not sure what culture you're referring there? There are coders out
there working with compilers which have this sort of diagnostic, but
don't bother learning about it an turning it on. I would hope that's
just a subculture. Why would it ever be a priority not to disturb
that subculture?

--
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 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.
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.
>
> 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.
>
> Say under some simple rule requiring that that if reaching the end of a
> function is conditional on the value of one or more expressions,
> they must be constant expressions whose values prevent that.
>
> What would be undesirable about working with that?
>
> Say that mountains of legacy code aren't an issue. (Or that they
> are, but what else?)
>

On 07/09/2023 03:47, Malcolm McLean wrote:
> On Wednesday, 6 September 2023 at 19:49:24 UTC+1, David Brown wrote:
>> On 06/09/2023 18:37, Malcolm McLean wrote:
>>> On Wednesday, 6 September 2023 at 16:35:57 UTC+1, David Brown wrote:
>>>> On 06/09/2023 16:53, Malcolm McLean wrote:

>>> So a leaf function can simply
>>> "jump to link register" to return. A non-leaf function has to save the link
>>> register on the stack and retrieve it.
>> Correct.
>>> Since caller doesn't know whether a function is leaf or not, in this case
>>> the return address would have to be pushed by the callee.
>>>
>> In which case? What are you talking about?
>>
>> The caller never pushes the return address in RISC architectures with
>> link-and-jump calling mechanics.
>>
> No, but if callee is not leaf, then unless you've got a weird and wonderful ABI,
> the same register will be used for the link and jump to callee's subroutine.

Yes.

> So it has to be saved, then retrieved when callee returns.

Yes. It can save it on the stack, or in a call-preserved register.
This is exactly the same as a caller must do for any volatile registers
(registers that the ABI says the called function can change).

>
> Except for leaf functions, you do have a list of return addresses on the stack,
> but they are managed by callee, not caller.

OK (though they don't have to be on the stack).

>
> So, to go back to the original point, there's no particular reason the stack space
> for the return type has to be managed by the caller.

It is /possible/ for the stack space for large return types to be
allocated by the callee, both on CISC architectures and RISC with
link-and-jump (or whatever variant name a particular architecture uses).
And it is definitely easier on link-and-jump architectures. But it is
not done in practice - it is simpler and more consistent to use
callee-allocated stack space with C ABI's. (Of course the norm is to
use a register, or possibly several registers, unless the return type is
too big.)

I'm not arguing that callee-allocated return stack space is not
possible, merely that it is not done.

>
> If you're on hardware which has a hardware stack and a "ret" instruction that
> means "pop the stack and jump to the address you just popped" then yes,
> I take your point. Having caller allocate space for the return value will save
> you an instruction.

It will save you a lot more than a single instruction - it will be very
significantly faster, especially on "polished turd" systems like modern
x86-64 processors.

Feel free to look up ABI's for different RISC architectures, and see if
you can find one where there is callee-allocated returns on the stack
for large objects. The ones I have looked at in detail (mostly
targeting embedded RISC systems, such as ARM EABI and PPC EABI)

Another option would be to go to <https://godbolt.org> and try it out on
some of the many architectures supported there. See if you can find one
where "caller_source" does not start by allocating 1000 (or a little
more) bytes on the stack before calling "source()".

typedef struct Big {
unsigned char data[1000];
} Big;

extern Big source(void);
extern void sink(Big b);
extern Big eb;

void caller_source(void) {
Big b = source();
eb = b;
}

void caller_sink(void) {
Big b = eb;
sink(b);
}

Big callee_source(void) {
Big b = eb;
return b;
}

void callee_sink(Big b) {
eb = b;
}

On 06/09/2023 23:24, Bart wrote:
> On 06/09/2023 20:17, David Brown wrote:
>> On 06/09/2023 19:13, Bart wrote:
>
>>> So something is expected on the virtual stack. If that return
>>> statement is commented out, it generates:
>>>
>>>    getversion:
>>>       retfn
>>
>> There's your problem.  That will almost certainly be invalid (unless
>> you have a very odd ABI, or more steps in your code generation
>> sequence to add a "push").  But that's all a problem with your code
>> generator, not with the way C is defined.
>
> It highlights that the problem is deeper than it looks. There is
> something malformed about the function, since at the common return
> point, some paths to that point won't have a pushed return value.

I'm sorry, but you are completely wrong here. C defines what can be in
a function, and what the statements and expressions mean - if the C
syntax and constraint rules are followed, then by definition the code is
/not/ malformed. It may not be what you expect to see in a typical
function, but it is not malformed. And if you are making a C compiler,
you need to be able to handle this situation.

If you want to make a C compiler, you have to make a compiler for /C/.
You can't make a compiler for what you personally think C should be.
Well, of course you /can/ do that - but its usage will be limited. If
you only need it to compile, say, C code generated by your other
transpilers, then that's fine. If you want to limit your compiler to a
certain subset of C, or add extensions, then that's also okay - but
please document these features if you expect others to use it, and make
it clear that your compiler is not a conforming standard C compiler.
You can then compare it to other C compilers and claim "my compiler is
better for my uses because it does this" - but don't claim "other
compilers are wrong because mine does this".

>
> It's similar to trying to do this in C:
>
>   x = (a ? b);
>   x = (a ? b :)
>
> When a is false, what do you store in x? Surely you wouldn't use any old
> rubbish that was lying around. But here, the type system would object
> even if the malformed syntax could be sorted. That is the approach I use.
>

These expressions are not allowed in C, so it doesn't make a lot of
sense to talk about them or compare them to anything.

You could, if you wanted to, define a meaning to them as extensions.
Two obvious choices would be :

x = a ? b : x;

and

if (a) x = b;

These are normal C statement expressions and should be fine to implement.

>
>> The returned value is always returned in the register "return_reg".
>
> But I've a chosen a stack-based IR (register- or temp-based IRs are
> harder to work with).

OK.

But if you find the IR structure you have chosen makes it difficult to
implement the C language, then surely the issue is with that choice of
IR? You don't get to blame C for the internal choices /you/ made for
/your/ implementation!

You can happily say that your IR works well with some other languages
(your own languages, or other defined languages) - different IR setups
will be suitable for different languages, and one should not expect a
"one size fits all" solution. You can say you'd have preferred C to
have been defined differently. But your choice of implementation
details are your own.

>
>> An alternative method is to create a local variable called
>> "return_value" at the entry to any non-void function.  Then your IRs
>> become :
>>
>>      getversion :
>>          local return_value (char *)
>>          assign return_value, "0.99"
>>          ret
>>
>> and
>>
>>      getversion :
>>          local return_value (char *)
>>          ret
>>
>> The return value slot is always created and returned in the same way.
>> But in the second case, nothing is assigned to it.
>
> Yes, this can work; you just have the extra headache of removing those
> extraneous loads and stores.

I would not imagine it is a headache. Either your tool already has
optimisations to remove extra loads and stores, in which case one more
to remove doesn't matter, or it does not, in which case one more left in
doesn't matter. (You are targeting x86 - modern x86 processors are
really good at removing extra register movements in the hardware.)

>
> (On actual stack-based bytecode for a dynamic language, I reserve a
> zeroed stack slot for a return value. This allows functions to be called
> via references, without knowing if they are functions or procedures. A
> return value is always available in either case.
>
> With static code you don't expect to do that.)
>
> Although this can still leave the return value undefined even if the
> mechanism is sorted. You might say, you can do this anyway:
>
>     int x;
>     return x;
>
> But unitialised locals is a different subject.
>

That would be fine, as far as I can see - if the callee function runs
off the end, and the caller tries to use the return value, the
programmer can't expect any sensible results. It's all undefined
behaviour. So it doesn't matter what value is "returned" in this case.

But as final suggestion, how about you transform any non-void function
like this:

return_type foo(parameters...) {
// Do stuff
// Possibly return, possibly not
}

into :

return_type foo(parameters...) {
// Do stuff
// Possibly return, possibly not

return_type _missing_return;
return _missing_return;
}

Inject these two statements into the end of all non-void functions (or
possibly all non-void functions that do not have a "return" statement as
their final statement). Suddenly all your problems disappear.

And if you have dead-code elimination optimisations, that code gets
temporarily created and then removed. If you don't have such
optimisations, the worst that happens is the object code is marginally
bigger.

On 07/09/2023 10:37, David Brown wrote:
> On 06/09/2023 23:24, Bart wrote:

[Missing 'return value;']

> But as final suggestion, how about you transform any non-void function
> like this:
>
> return_type foo(parameters...) {
>     // Do stuff
>     // Possibly return, possibly not
> }
>
> into :
>
> return_type foo(parameters...) {
>     // Do stuff
>     // Possibly return, possibly not
>
>     return_type _missing_return;
>     return _missing_return;
> }
>
> Inject these two statements into the end of all non-void functions (or
> possibly all non-void functions that do not have a "return" statement as
> their final statement).  Suddenly all your problems disappear.

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 helps with this compilation. The issue will still exist in the
source code however, and with another compiler, things can be different.
Making this a compile error would literally be fixing it at source.

> And if you have dead-code elimination optimisations, that code gets
> temporarily created and then removed.  If you don't have such
> optimisations, the worst that happens is the object code is marginally
> bigger.

This is exactly the argument you can apply by insisting the user writes
an explicit 'return 0;' for example at the end of a non-void function,
if a compiler reports that one might be needed.

This will fix any potential problems once and for all across all
compilers, dialects and options.

On Thursday, 7 September 2023 at 10:11:17 UTC+1, David Brown wrote:
> On 07/09/2023 03:47, Malcolm McLean wrote:
>
> > If you're on hardware which has a hardware stack and a "ret" instruction that
> > means "pop the stack and jump to the address you just popped" then yes,
> > I take your point. Having caller allocate space for the return value will save
> > you an instruction.
> It will save you a lot more than a single instruction - it will be very
> significantly faster, especially on "polished turd" systems like modern
> x86-64 processors.
>
CALLER_ALLOCATED.

write return to stack.
ret (pop stack and jump to address popped, in one instruction).

CALLEE_ALLOCATED

pop stack, and put result in register X
push return onto stack
jump to address in register X

I make that one instruction saved for CALLER_ALLOCATED.

On 07/09/2023 13:04, Malcolm McLean wrote:
> On Thursday, 7 September 2023 at 10:11:17 UTC+1, David Brown wrote:
>> On 07/09/2023 03:47, Malcolm McLean wrote:
>>
>>> If you're on hardware which has a hardware stack and a "ret" instruction that
>>> means "pop the stack and jump to the address you just popped" then yes,
>>> I take your point. Having caller allocate space for the return value will save
>>> you an instruction.
>> It will save you a lot more than a single instruction - it will be very
>> significantly faster, especially on "polished turd" systems like modern
>> x86-64 processors.
>>
> CALLER_ALLOCATED.
>
> write return to stack.
> ret (pop stack and jump to address popped, in one instruction).
>
> CALLEE_ALLOCATED
>
> pop stack, and put result in register X
> push return onto stack
> jump to address in register X
>
> I make that one instruction saved for CALLER_ALLOCATED.

I don't care how many instructions you think it saves - especially in
the completely unrealistic situation of a return value that can be
pushed directly to the stack. (If the return data fits in a register,
it will be returned in a register - not the stack.)

The /time/ difference is very different, because the hardware on these
kinds of processors is heavily geared towards return calls. There are
dedicated return stack buffers for the purpose, pre-fetching and
speculative execution that all work on the basis of normal ABI's with
normal returns. You throw all that out by having a pointless
upside-down and non-standard ABI for return values.

Perhaps for some languages it would make more sense to have callee
allocation of return values on a stack (though none that I can think of,
except perhaps Forth) - but not for C. Not on RISC architectures, and
certainly not on CISC systems.

Can we now leave this be? It is not relevant to C, not helpful to the
discussion, and your hypothetical speculation is going nowhere. I claim
that no C ABI's have callee allocation of return values on the stack.
Prove me wrong and I will happily apologise, and be glad to learn
something new. Until then, please drop this.

On 07/09/2023 12:53, Bart wrote:
> On 07/09/2023 10:37, David Brown wrote:
>> On 06/09/2023 23:24, Bart wrote:
>
> [Missing 'return value;']
>
>> But as final suggestion, how about you transform any non-void function
>> like this:
>>
>> return_type foo(parameters...) {
>>      // Do stuff
>>      // Possibly return, possibly not
>> }
>>
>> into :
>>
>> return_type foo(parameters...) {
>>      // Do stuff
>>      // Possibly return, possibly not
>>
>>      return_type _missing_return;
>>      return _missing_return;
>> }
>>
>> Inject these two statements into the end of all non-void functions (or
>> possibly all non-void functions that do not have a "return" statement
>> as their final statement).  Suddenly all your problems disappear.
>
> 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.

If you like, you can do that. I personally don't see that as an
advantage for how I use C (as you know, I am happy to see a number of
things undefined or unspecified). But if you do, I have no problem with
that, and I see no conflict with the C standards if you choose to
implement things that way.

>
> That helps with this compilation. The issue will still exist in the
> source code however, and with another compiler, things can be different.

If the code has defined behaviour (i.e., the function may be called, but
its non-existent return value is not used), then the results will be the
same. If the code has undefined behaviour (by trying to use the value),
the results could be different. This is exactly as you would normally
expect when different compilers are faced with code with undefined
behaviour - there are no guarantees or even expectations of getting the
same results, and you should not worry about that.

> Making this a compile error would literally be fixing it at source.

But it is not an error in the source - not in standard C.

I still think it is good if your compiler gives at least a warning, and
perhaps an error, as an option or even by default. But if you want your
tool to be a conforming C compiler, in at least some modes, then you
have to accept such code and compile it with the behaviour dictated by
the C standards.

>
>
>> And if you have dead-code elimination optimisations, that code gets
>> temporarily created and then removed.  If you don't have such
>> optimisations, the worst that happens is the object code is marginally
>> bigger.
>
> This is exactly the argument you can apply by insisting the user writes
> an explicit 'return 0;' for example at the end of a non-void function,
> if a compiler reports that one might be needed.
>
> This will fix any potential problems once and for all across all
> compilers, dialects and options.
>

No, not at all.

For one thing, some compilers might warn about the useless code of
adding an unreachable "return 0;". Secondly, some programmers or code
reviewers might complain about it - I certainly would.

Adding "return 0;" to the user code is a user-visible change and a user
requirement. This makes it vastly more costly, in many senses of the
word, than a hidden internal change inside the implementation.