Bart <bc@freeuk.com> writes:
> On 05/09/2023 01:16, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 05/09/2023 00:04, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>> [...]
>>>>> All I know is that the family/dialect/standard in each case doesn't
>>>>> care amount making a missing 'return <value>' a hard error. So else
>>>>> are they being being lax over?
>>>> I have what I think is a very simple question for you. Will you
>>>> acknowledge that the ISO C standard does not require a diagnostic
>>>> for a missing return statement in a non-void function?
>>>> I'm asking you for nothing more than a "yes" or "no" answer. You
>>>> can
>>>> of course follow that with anything you like, but a "yes" or "no"
>>>> would be helpful -- or a brief explanation of why you think neither
>>>> "yes" nor "no" is a meaningful answer.
>>>> [...]
>> I note your refusal to answer this simple question.
>
> If you mean this:
>
>> Will you
> acknowledge that the ISO C standard does not require a diagnostic
> for a missing return statement in a non-void function?
>
> Then I don't know. I will have to take somebody's word for it. You
> seem to be implying the answer is Yes, so Yes.

You've written a C compiler.

I cannot imagine even trying to do that without referring to the ISO C
standard.

The answer to the question is yes. The ISO C standard does not require a
diagnostic for a missing return statement in a non-void function.

I can post the URL of an appropriate draft of the standard, along with
specific citations that demonstrate that no such diagnostic is required.
But I probably won't bother, since you'll only complain about it and
pretend not to understand it.

> In my revised C compiler, I've taken out the -old option (it is now
> the default), and no longer bother to the extra check for a solid
> return value from a non-void function. Since nobody else cares, I'm
> not going to either, and you are now saying I can do that.

Why on Earth would you do that? You have completely misunderstood this
discussion, apparently deliberately. Such warnings are common, useful,
and permitted (though not required) by the ISO C standard. I have not
said anything about what you can or cannot do with your own compiler.

Rejecting a program (as opposed to issuing a non-fatal warning) because
of a missing return statement would make your compiler non-conforming.
I do not care whether your compiler is conforming or not, and you've
made it clear that you don't either.

> (I may, however, need to insert an all-zeros return value in the
> generated code, since the IR is stack-based and that becomes more
> critical.)
>
> But both of the following are still hard errors:
>
> int fred(void) {return;}
> void bill(void) {return 1;}

Both of those are constraint violations, requiring a diagnostic from any
conforming C compiler. Making them "hard errors" is a good idea. It's
not much to brag about, but good for you.

--
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 05/09/2023 21:37, David Brown wrote:
> On 05/09/2023 21:57, Bart wrote:

>> 6.8.6.4p1 says:

>> It doesn't say anything about Non-void functions, so we have to draw
>> inferences: presumably (1) must be 'Only here', and (2) must be 'Not
>> allowed'. So:
>>
>>                     (Proc)        (Func)           (My terms)
>>                     Void func     Non-void func
>>
>>    return expr;     N             Y
>>
>>    return;          Y             N
>>
>> A bit clearer, yes? Maybe /I/ should be writing it! I already
>> implement these because they are common sense, but the question was,
>> what should a compiler do about infringements.
>>
>> This paragraph calls them Constraints, as presumably they can't be
>> expressed via syntax.
>
> Yes.  (Or at least, the rules are not expressed by the syntax - maybe
> they could have been, but it seemed easier to express them as constraints.)
>
>>
>> I guess some other sections explains how those are handled.
>
> It's all quite clear - you got it.  (There are certainly some parts of
> the standard that are harder to figure out.)
>
> Note that it does not say anywhere that you /must/ have a return
> statement - with or without an expression.  It merely says what kind of
> return statements are allowed.  So there is no requirement anywhere here
> for a function to have a "return <expression>" statement even if the
> function is non-void.

So my summary was wrong. It is more like this:

(Proc) (Func) (My terms)
Void func Non-void func

return expr; N Optional

return; Optional N

Optional for a procedure is right, since running into the end of the
function is OK because the compiler will ensure there is a 'return' there.

So my main disagreement is with the Optional return of non-void
functions (which I've now given up on), and how seriously infringements
of those 'N' cases are reported.

Because a compiler could also have have ensured that running into the
end of a non-void function sets up a default return value such as all-zeros.

> Running off the end of a non-void function is only a problem if the the
> caller tries to use the value.

Which in general you can't determine, and is incredibly sloppy anyway.

>  Otherwise it is fine.

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.

>> You sound like a Jehovah's Witness.
>
> The difference is, the C standard is real.

They're both written by humans.

> Once you know what it says here, so you understand how the language is
> defined, /then/ it makes sense to ask /why/ it is defined that way. (And
> I quite appreciate that you want to know why - I too like to know the
> reasons behind decisions.)
>
>>
>>> And stick to one thing at a time.  Two thoughts on the same day
>>> appear to be beyond you, and we don't want you to get confused again.
>>
>> Yeah, well I'm busy actually implementing C at the moment.

> Well, I'm glad you have now found a copy of one of the C standards
> (which one?), and are starting to show an interest in finding out how
> the language is defined.

You really think I haven't looked at it before?

> It will make it much easier to write a C
> implementation.

99% of the work is nothing to do with the standard. It's a slog. A lot
of it caused by so much diversity in all the C code out there, /because/
people have too much freedom to write what they like.

Bart <bc@freeuk.com> writes:
[...]
> This paragraph calls them Constraints, as presumably they can't be
> expressed via syntax.

Or just because it's inconvenient to express them via syntax.

> I guess some other sections explains how those are handled.
[...]

Yes, constraints are explained in N1570 5.1.1.3 "Diagnostics":

A conforming implementation shall produce at least one
diagnostic message (identified in an implementation-defined
manner) if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint,
even if the behavior is also explicitly specified as undefined
or implementation-defined. Diagnostic messages need not be
produced in other circumstances.

with a footnote:

The intent is that an implementation should identify the nature of,
and where possible localize, each violation. Of course, an
implementation is free to produce any number of diagnostics as long
as a valid program is still correctly translated. It may also
successfully translate an invalid program.

Is that clear enough for you?

--
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 05/09/2023 22:07, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> This paragraph calls them Constraints, as presumably they can't be
>> expressed via syntax.
>
> Or just because it's inconvenient to express them via syntax.
>
>> I guess some other sections explains how those are handled.
> [...]
>
> Yes, constraints are explained in N1570 5.1.1.3 "Diagnostics":
>
> A conforming implementation shall produce at least one
> diagnostic message (identified in an implementation-defined
> manner) if a preprocessing translation unit or translation
> unit contains a violation of any syntax rule or constraint,
> even if the behavior is also explicitly specified as undefined
> or implementation-defined. Diagnostic messages need not be
> produced in other circumstances.
>
> with a footnote:
>
> The intent is that an implementation should identify the nature of,
> and where possible localize, each violation. Of course, an
> implementation is free to produce any number of diagnostics as long
> as a valid program is still correctly translated. It may also
> successfully translate an invalid program.
>
> Is that clear enough for you?
>

Yeah, thanks.

It sounds like these are guidelines. Which is good, as I have my own
ideas of how my compilers will work (my first one was 43 years ago!).

I can tell you I don't think much of this:

"It may also successfully translate an invalid program."

I think I'd rather not! What is the incentive in writing a /valid/
program if you will get an executable either way?

On 2023-09-05, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> You've written a C compiler.
>
> I cannot imagine even trying to do that without referring to the ISO C
> standard.

So you might say in earnest, and on the surface it's a fine enough
sentiment, and rings true in reference to the entire activity from start
to finish.

It seems it would actually be a good idea to initially write as much of
it as you're able to from your knowledge as a sort of "closed book exam"
before cracking open the standard. "Do I know this stuff well enough to
implement it, and to what detail?"

Relying on what you know would go pair well with a top-down design,
guided by your mental map of the language until the bottom-level details
start to become critical.

Needless to say, writing a C compiler without planning on ever looking into
ISO C is not such a hot idea though.

--
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 05/09/2023 21:37, David Brown wrote:
>> On 05/09/2023 21:57, Bart wrote:
>>> 6.8.6.4p1 says:
>>> It doesn't say anything about Non-void functions, so we have to
>>> draw inferences: presumably (1) must be 'Only here', and (2) must
>>> be 'Not allowed'. So:
>>>
>>>                     (Proc)        (Func)           (My terms)
>>>                     Void func     Non-void func
>>>
>>>    return expr;     N             Y
>>>
>>>    return;          Y             N

I believe that's an accurate summary of 6.8.6.4p1.

[...]

> So my summary was wrong. It is more like this:
>
> (Proc) (Func) (My terms)
> Void func Non-void func
>
> return expr; N Optional
>
> return; Optional N

It's true that a return statement is optional, but it's not 6.8.6.4p1
that says so.

(In fact the standard doesn't *explicitly* say that a return statement
is optional. It follows from the fact that there is no rule requiring a
return statement, and from explicit statements about what happens if the
closing } of a non-void function is reached.)

> Optional for a procedure is right, since running into the end of the
> function is OK because the compiler will ensure there is a 'return'
> there.
>
> So my main disagreement is with the Optional return of non-void
> functions (which I've now given up on), and how seriously
> infringements of those 'N' cases are reported.

At least you *finally* agree about what the standard says. Perhaps now
we can discuss the reasons.

The standard does not require a diagnostic for reaching the closing } of
a non-void function because it's impossible to detect that at compile
time in all cases.

It does not require a diagnostic for a non-void function that doesn't
have a return statement *somewhere* because that would miss a lot of
potential errors (this is my speculation about the reason):

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

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. It requires analysis
that most compilers already do for the purpose of optimization and
issuing optional warnings. Someone would have to make a formal
proposal, and it would have to be approved by WG14. It was not
done originally because (I speculate) the required analysis would
have been a significant burden on compilers at the time, and perhaps
nobody thought of it.

Meanwhile, any (conforming) C compiler is free to do that analysis and
issue a non-fatal warning if it can determine that a non-void function
will, or even might, reach its closing }. It can even reject such a
program in a non-conforming mode. gcc and clang can be made to do so
with the right options.

I suppose another possibility would be to require an implicit call to
abort() immediately before the closing } of any non-void function (other
than main()). The call could be optimized away if the compiler can
determine that it's never reached. Such a requirement would not apply
to a freestanding implementation. I haven't decided whether that would
be a good idea or not.

[...]

--
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 05/09/2023 22:07, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> This paragraph calls them Constraints, as presumably they can't be
>>> expressed via syntax.
>> Or just because it's inconvenient to express them via syntax.
>>
>>> I guess some other sections explains how those are handled.
>> [...]
>> Yes, constraints are explained in N1570 5.1.1.3 "Diagnostics":
>> A conforming implementation shall produce at least one
>> diagnostic message (identified in an implementation-defined
>> manner) if a preprocessing translation unit or translation
>> unit contains a violation of any syntax rule or constraint,
>> even if the behavior is also explicitly specified as undefined
>> or implementation-defined. Diagnostic messages need not be
>> produced in other circumstances.
>> with a footnote:
>> The intent is that an implementation should identify the nature of,
>> and where possible localize, each violation. Of course, an
>> implementation is free to produce any number of diagnostics as long
>> as a valid program is still correctly translated. It may also
>> successfully translate an invalid program.
>> Is that clear enough for you?
>
> Yeah, thanks.

You're welcome.

> It sounds like these are guidelines. Which is good, as I have my own
> ideas of how my compilers will work (my first one was 43 years ago!).
>
> I can tell you I don't think much of this:
>
> "It may also successfully translate an invalid program."
>
> I think I'd rather not! What is the incentive in writing a /valid/
> program if you will get an executable either way?

You know what? I (mostly) agree with you. I would have preferred it if
the C standard had required any translation unit that violates a syntax
rule or constraint must be rejected (not generate an object file, and
not be linkable into an executable program).

You see, once we have a mutual understanding about what the standard
says, I'm willing to discuss what I think it should say.

On the other hand, it's not that much of a problem in practice.

For example, "gcc -std=c17 -pedantic" is a conforming C compiler that
will generate an executable for many programs that have constraint
errors. "gcc -std=c17 -pedantic-errors" is a conforming C compiler that
will *not* generate an executable for any program that violates a syntax
rule or constraint. (Or rather, it attempts to be conforming; there are
always bugs.)

And if you wanted to write an ISO conforming C compiler, you could make
it unconditionally reject any translation unit that violates a syntax
rule or constraint. The standard allows that. (Neither of us is
entirely happy about the fact that it doesn't require it, but I can live
with it.)

Even if a future edition of the standard required compilers to reject
syntax errors and constraint violations, compilers could still have a
non-conforming mode that treats some of them as non-fatal errors, or
even ignores them.

--
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 9/5/23 2:22 PM, Bart wrote:

> It sounds like these are guidelines. Which is good, as I have my own
> ideas of how my compilers will work (my first one was 43 years ago!).
>
> I can tell you I don't think much of this:
>
> "It may also successfully translate an invalid program."
>
> I think I'd rather not! What is the incentive in writing a /valid/
> program if you will get an executable either way?
>

Because the conversion of a valid program has defined behavior by the
Standard.

If an "invalid" program (by the Standard) results in a successful
translation" then running such a result has Undefined Behavior (by the
Standard)

The reason for allowing this, is that the implementation might be
defining the meaning of the "invalid" code, and thus the behavior of the
result.

Generally, most "invalid" conditions that just generate warnings (and
thus allow a successful translation) have a meaning supplied by the
implementation, which is why they just become warnings.

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

> On Tuesday, 5 September 2023 at 01:31:48 UTC+1, Ben Bacarisse wrote:
>>
>> > Do you have your own examples in other languages which do the same: return
>> > whatever garbage is in a register, since the language allows you to omit an
>> > explicit value?
>> If "the language" is C, then it does not allow any such thing. And the
>> program you posted does not "do" anything. It is as meaningless and any
>> and all other undefined C programs.
>>
> Originally C didn't have a void type. So
>
> if (foo())
>
> was always a legitimate statement.

For some values of "legitimate". It's never been legitimate in the
sense of "being in accordance with established or accepted rules" when
foo does not return a value determined by the programmer. The accepted
rules of programming include not making a choice based on garbage data.

It is syntactically legitimate, but using the term unqualified could
suggest to readers that it was once a reasonable thing to write.

> If foo() couldn't sensibly return a value, then it would default to
> int, and ...

If foo() couldn't sensibly return a value, then the programmer would
usually omit the return type as a hint to the reader. Since missing
types defaulted to int ...

> ... whatever garbage was in the register used for passing back
> values would be used. This wasn't ideal, but it probably made the
> very primitive first compilers easier to write.
>
> It's hung on to the present day.

What's the "it" refer to? Neither the default int rule nor returning
whatever is in a particular register could be taken to apply anymore.
The rule has changed, and modern compilers don't always behave that
predictably. Optimisation, in particular, is likely to make the
behaviour quite different.

> 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 and expecting people to sometimes add junk return statements is
less than ideal. Modern compilers can detect lots of the cases and can
be told to reject such programs which make the problem much less
significant (for people who are prepared to use compiler flags).

> though as some people have
> pointed out, in some case you would have to add dummy returns on control paths
> which couldn't in fact be followed, to help the compiler out.

--
Ben.

Bart <bc@freeuk.com> writes:

> On 05/09/2023 01:31, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 04/09/2023 14:54, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 04/09/2023 09:54, David Brown wrote:
>>>>>> On 03/09/2023 19:11, Bart wrote:
>>>>>
>>>>>>> What's wrong with that?
>>>>>> If you can live inside a bubble, and be happy with that, then I suppose
>>>>>> that's fine.  However, you don't have the experience or understanding to
>>>>>> criticise those outside the bubble.  You can live in your blissful
>>>>>> ignorance if that's what suits you - but please understand that others do
>>>>>> not want to be in your bubble.  It does not appeal at all to me. Your
>>>>>> bubble tools and languages are of little use or interest to all but a
>>>>>> very few other people.
>>>>>
>>>>> That may be so. But you can still learn things from them.
>>>> I think I've asked before, but is there a language reference manual?
>>>
>>> No.
>> Then no significant learning can happen.
>
> It's not going to happen anyway. I'm not going to spend a month slaving
> over a document just so you can say:

I would never expect you write a manual just for me. I had thought you
have user who would want to know the details.

> <snip>

You said you didn't like my writing that and I stopped. Had you not
noticed? I will still cut discussion of code that only you have a
reference manual for, but I won't write "<snip>" to indicate that
editing.

>>> Do you have your own examples in other languages which do the same: return
>>> whatever garbage is in a register, since the language allows you to omit an
>>> explicit value?
>> If "the language" is C, then it does not allow any such thing. And the
>> program you posted does not "do" anything. It is as meaningless and any
>> and all other undefined C programs.
>
> 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).

This text:

int main(void) { int a[] = {1}; return a[2]; }

is meaningless (as C). It does not "do" anything because it means
nothing.

You can choose to say that it's meaning is what the generated code does
(since most compilers will generate an executable) but then you link the
meaning of a text to the whims of a compiler author, the version of the
compiler and even to the flags you use when compiling.

> I posted examples of something that looked like C code, and of running
> programs that people often use to compile C code, which turned that code
> into an executable that promptly crashed.
>
> But that's impossible, because C 'doesn't allow it'? Another wind-up?

I didn't say it was impossible. C says "that's meaning less junk text"
but the compiler said "OK, here's some code I decided to generate from
that text" and that code crashes.

You want C to have rules that mean that this specific type of error can
never occur. I am happy with a compiler that tells me (as gcc does when
ask to) that this code is junk.

>> And the
>> program you posted does not "do" anything.
>
> Let's say the intention is to call a function to return a string. But that
> return statement has been left out. So it's undefined. But, that's OK?

C says that is not OK (if the value is used). I say it's not OK as well.

> 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

> 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 can certainly complain that gcc did
not work hard enough to stop you, but gcc sees itself as a tool not a
teacher.

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

> * That code was not C

It has no meaning when interpreted as C.

> * That had undefined behaviour

Code does not "have" undefined behaviour. C code either has a meaning
given to it by the language standard or it does not. UB means the
language no longer says what the source code means. All bets are off.

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

> Anything to put me in the wrong and absolve C and that C compiler invoked
> by gcc from any blame in passing a program that could have wiped my hard
> drive.
>
> I don't get it. But, I really no longer care.

Seriously, if you don't care, don't post. I've tried to explain my
remarks to you and that takes time. If you really don't care, I've
wasted my time. At the very least, put "I don't care" near the top as
you did when you told me not to bother answering.

> You want to pretend that there is nothing really wrong that writing your
> own compiler preprocessor can't fix, then fine.

You keep interpreting my replies as meaning that I think there is
nothing wrong with C.

Running gcc with no flags and complaining that it does not report a
syntax error is simply daft because gcc (with no flags) is not a C
compiler -- it interprets its input according to rules that are not
those of the C standard. You then find something else you don't like
(an un-diagnosed missing return value) so I tell you how to have it
diagnosed. But you don't like that gcc makes up some target code
anyway, so I tell you how to stop that and, in passing, explain how I
think about junk C code and what compilers do with it.

None of that means I think there is nothing wrong. The trouble is I
don't think I know exactly what's wrong and how to fix it. Do I think
your examples show a problem? Not really as I don't ignore it when gcc
tells me there's a missing return. And for the more complicated real
life examples, do I want to be made to add a fake return statement? No,
I think if you twisted my arm I'd want something more like an attribute
or a new kind of assert. And if C had codified rules about
reachability, I'd want exit and longjmp to be factored in as well. But
is that a good idea? I don't know.

--
Ben.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> 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).
[...]

A very small quibble. I haven't found anything in gcc's documentation
that says it allows that extra semicolon. It does have a diagnostic
message that's enabled by -pedantic, but unless I'm missing something,
the lack of documentation means that it's not an *extension* in the
sense defined in section 4 of the C standard.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Ergonomics experts often design interfaces that I find hard to
>>> use. To take one example, I want to use common key binding across
>>> applications, but the experts seem to think there is only one such
>>> set (and it comes from an OS I have not used for years), so I
>>> can't use the bindings my fingers "know" about.
>>
>> I'm curious to know more about the specifics here. What key
>> bindings, which "one set to rule them all", what domain of
>> applications followed that set?
>
> I like to use Emacs keybindings. I can use them in bash and programs
> that use GNU readline which includes a lot of REPL programs like ghci,
> swipl, gp and so on. I can't use them in the Gnome browser.

Clearly emacs needs to add M-x new-browser-frame .

By the way, have you tried the Brave browser? I haven't
yet but am thinking about it. (The question here is
mostly rhetorical, feel free to duck it unless you really
want to answer.)

> One big annoyance is not strictly to do with keys but is UI-related. I
> am used to having selected text available for immediate pasting with the
> middle button, but several applications have started to auto select text
> in certain situations and I loose my selection.

Clearly a need for selection rings so ESC <middle button> would
paste the second most recent selection, etc.

More seriously, one-level-deep "clipboards" really bug me. I
know one is a lot lot better than zero, but even just two or
three would be a lot better than one. (And don't get me started
on so-called "browser history".)

>> Also I'm curious to know how
>> you know (or why you suspect) the choices were made by experts?
>
> I don't. Maybe I should have put "experts" it scare quotes. I stated
> to notice the loss of configuration when Gnome got a team in to clean up
> the interface and develop a set of rules to simplify things for the
> average user. They may not have been experts, but the announcement
> suggested they were.

I see. I've been trying different u/li/nux windowing systems
recently, haven't found one yet that I really like (or at
least can stand). I got a suggestion to try xfce, which I
expect to do someday.

>> What abilities or skills qualify them as experts?
>
> Too big a topic. I hope you won't mind if I just don't even try to
> answer that.

Don't mind at all.

Probably I should mention that I am used to associating the word
ergonomics with (mostly) physical attributes, and not so much
with logical attributes like key bindings. Maybe the word has
expanded its scope since I first learned it.

That said, your answers here have been quite illuminating.

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. But it is not a text which has
a meaning but a device which achieves a result.
>
> >> And the
> >> program you posted does not "do" anything.
> >
> > Let's say the intention is to call a function to return a string. But that
> > return statement has been left out. So it's undefined. But, that's OK?
>
> C says that is not OK (if the value is used). I say it's not OK as well.
>
> > 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
>
> > 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 can certainly complain that gcc did
> not work hard enough to stop you, but gcc sees itself as a tool not a
> teacher.
>
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.

Does the program mean anything? Well yes, the identifier getversion() conveys
a meaning to the human reader. Clearly we are trying to print out a version
number of some kind, and, because function doesn't have a return statement,
clearly we don't have it. It needs fixing, which would be achieved by asking
"what's the current version number?" and putting it in. Of course the compiler
is nowhere near clever enough to understand that.
>
> > 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. If an executable results, the
input has been accepted, otherwise it has been rejected.
>
> > * That code was not C
>
> It has no meaning when interpreted as C.
>
> > * That had undefined behaviour
>
> Code does not "have" undefined behaviour. C code either has a meaning
> given to it by the language standard or it does not. UB means the
> language no longer says what the source code means. All bets are off.
>
> > * 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.
>
> > Anything to put me in the wrong and absolve C and that C compiler invoked
> > by gcc from any blame in passing a program that could have wiped my hard
> > drive.
> >
> > I don't get it. But, I really no longer care.
>
> Seriously, if you don't care, don't post. I've tried to explain my
> remarks to you and that takes time. If you really don't care, I've
> wasted my time. At the very least, put "I don't care" near the top as
> you did when you told me not to bother answering.
>
> > You want to pretend that there is nothing really wrong that writing your
> > own compiler preprocessor can't fix, then fine.
>
> You keep interpreting my replies as meaning that I think there is
> nothing wrong with C.
>
> Running gcc with no flags and complaining that it does not report a
> syntax error is simply daft because gcc (with no flags) is not a C
> compiler -- it interprets its input according to rules that are not
> those of the C standard. You then find something else you don't like
> (an un-diagnosed missing return value) so I tell you how to have it
> diagnosed. But you don't like that gcc makes up some target code
> anyway, so I tell you how to stop that and, in passing, explain how I
> think about junk C code and what compilers do with it.
>
> None of that means I think there is nothing wrong. The trouble is I
> don't think I know exactly what's wrong and how to fix it. Do I think
> your examples show a problem? Not really as I don't ignore it when gcc
> tells me there's a missing return. And for the more complicated real
> life examples, do I want to be made to add a fake return statement? No,
> I think if you twisted my arm I'd want something more like an attribute
> or a new kind of assert. And if C had codified rules about
> reachability, I'd want exit and longjmp to be factored in as well. But
> is that a good idea? I don't know.
>
It's easy enough for the compiler to detect if a control path is unreachable
with no false positives. But it's impossible to remove all the false negatives
(code which is in fact unreachable, but falsely labelled as reachable).
It's also often difficult for a human to make the same determination.
So if you require dummy return statements, this can have a serious impact
on the reader's ability to understand the code.
However we can easily solve the problem. Simply define a macro with the
value 0 in the file assert.h, then
assert(UNREACHABLE);
The code following then becomes trivially unreachable.

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.

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?

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

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.

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

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.

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.

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

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.

So the objection is silly. (Note that in generated code, you may be
merely transpiling a cast in the original language of T(X) to the C
equivalant which is (T)X, and in both that language and the targets of
interest, the conversion is well-defined.)

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

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

> You can certainly complain that gcc did
> not work hard enough to stop you, but gcc sees itself as a tool not a
> teacher.

As I explained, in my language it is impossible for a non-void function
to run into the end of function without an explicit 'return value' or
equivalent (without going beyond the language).

(Which can be a nuisance when you have new functions not yet populated,
nor yet called, but it is also a minor one. Rules are rules, which here
are to do with the type system. Bypass that one, and I might as well
allow 'a[i] := ;' because I haven't yet gotten around to working out the
RHS of that assignment.)

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

Maybe it checks for the right compiler before it looks at those options,
but by themselves, they don't tell gcc to be expecting C input.

> Running gcc with no flags and complaining that it does not report a
> syntax error is simply daft because gcc (with no flags) is not a C
> compiler -- it interprets its input according to rules that are not
> those of the C standard.

So it compiles a C subset or superset. Clearly it's not compiling APL;
we can call it C, especially since gcc derives knowledge of the language
it is compiling from the file extension, and in all examples I've shown,
that is .c. You are stating that:

gcc prog.c

is not compiling C. That is not right.

On 05/09/2023 23:05, Bart wrote:
> On 05/09/2023 21:37, David Brown wrote:
>> On 05/09/2023 21:57, Bart wrote:
>
>>> 6.8.6.4p1 says:
>
>>> It doesn't say anything about Non-void functions, so we have to draw
>>> inferences: presumably (1) must be 'Only here', and (2) must be 'Not
>>> allowed'. So:
>>>
>>>                     (Proc)        (Func)           (My terms)
>>>                     Void func     Non-void func
>>>
>>>    return expr;     N             Y
>>>
>>>    return;          Y             N
>>>
>>> A bit clearer, yes? Maybe /I/ should be writing it! I already
>>> implement these because they are common sense, but the question was,
>>> what should a compiler do about infringements.
>>>
>>> This paragraph calls them Constraints, as presumably they can't be
>>> expressed via syntax.
>>
>> Yes.  (Or at least, the rules are not expressed by the syntax - maybe
>> they could have been, but it seemed easier to express them as
>> constraints.)
>>
>>>
>>> I guess some other sections explains how those are handled.
>>
>> It's all quite clear - you got it.  (There are certainly some parts of
>> the standard that are harder to figure out.)
>>
>> Note that it does not say anywhere that you /must/ have a return
>> statement - with or without an expression.  It merely says what kind
>> of return statements are allowed.  So there is no requirement anywhere
>> here for a function to have a "return <expression>" statement even if
>> the function is non-void.
>
>
> So my summary was wrong. It is more like this:
>
>                      (Proc)        (Func)           (My terms)
>                      Void func     Non-void func
>
>     return expr;     N             Optional
>
>     return;          Optional      N
>
> Optional for a procedure is right, since running into the end of the
> function is OK because the compiler will ensure there is a 'return' there.

I took the "Y" in your first summary to mean "yes, this is allowed". If
you prefer to write that as "optional", that's fine.

>
> So my main disagreement is with the Optional return of non-void
> functions (which I've now given up on), and how seriously infringements
> of those 'N' cases are reported.

Just to be clear here - and I /really/ hope you will answer this one
simply and unambiguously - do you understand that the C standards make
the return statement optional? Do you understand that this is what the
C standards say - it is not something that C compilers choose, or that C
programmers in this group have decided?

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.

This all follows a common pattern for C - the standards define what
useful and meaningful code does, but do not attempt to enforce good
programming practice, since that varies hugely for different use-cases.
It is up to tools to aid users in their development, not the C language.
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. And the preferences for different
programmers vary wildly. Since most tools are targeted at many
different people and coding styles, they support options to let users
decide what they need. Other tools are more specialised - specific
checkers for the Linux kernel, MISRA rule checkers for the automotive
industry, and so on. (C tools are not restricted to compilers - from
its inception, it was expected that linters and other checkers would be
independent from compilers.)

Sometimes there are things that perhaps 95% of users agree is likely to
be bad coding. A tool might flag the potential error by default - but
it might not, for many different reasons. Even if 99.9% of users agree,
however, it is not the compiler's job to overrule the definition of the
language in the standards - it has to allow the code. It can give
warnings, it can require flags or options, but it has to allow it.

>
> Because a compiler could also have have ensured that running into the
> end of a non-void function sets up a default return value such as
> all-zeros.

A compiler certainly /could/ do that. I'd question the usefulness of
it, but maybe some people would like it. My own preference, as you
know, is for the compiler to detect and flag potential problems such as
running off the end of a non-void function as a hard error - just like
your preference. The only differences are that I know that I am asking
for a subset of C, I am asking for a restriction that not everyone
wants, I understand that C compilers should not have this kind of
restriction as a default, and I know how to ask my tools to enforce the
restrictions I want.

>
>> Running off the end of a non-void function is only a problem if the
>> the caller tries to use the value.
>
> Which in general you can't determine, and is incredibly sloppy anyway.
>

Most run-time errors can't be determined in advance - certainly not by
simple static rules. (Again, I prefer warnings or even errors for this
situation - but that is /my/ preference, and is not a requirement of the
C standards, and not what all C programmers want in all circumstances.)

>
>>   Otherwise it is fine.
>
> 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.

>>> You sound like a Jehovah's Witness.
>>
>> The difference is, the C standard is real.
>
> They're both written by humans.

I don't really want to get into religious discussions. But you could
read through the C standards in a day and have a pretty good idea of
most of it, and be familiar enough to find the references you need when
you want them. It would probably take a couple of years to reach the
same level of familiarity with the Bible - the comparison between the
two documents is clearly absurd.

>
>> Once you know what it says here, so you understand how the language is
>> defined, /then/ it makes sense to ask /why/ it is defined that way.
>> (And I quite appreciate that you want to know why - I too like to know
>> the reasons behind decisions.)
>>
>>>
>>>> And stick to one thing at a time.  Two thoughts on the same day
>>>> appear to be beyond you, and we don't want you to get confused again.
>>>
>>> Yeah, well I'm busy actually implementing C at the moment.
>
>> Well, I'm glad you have now found a copy of one of the C standards
>> (which one?), and are starting to show an interest in finding out how
>> the language is defined.
>
> You really think I haven't looked at it before?

I don't think you have made noticeable effort to read it or understand
it, no.

>
>> It will make it much easier to write a C implementation.
>
> 99% of the work is nothing to do with the standard. It's a slog. A lot
> of it caused by so much diversity in all the C code out there, /because/
> people have too much freedom to write what they like.
>

The standard is what defines the language. How could it not be important?

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

It's just a minor implementation decision. But if you choose option two,
then callee has to push something even if control falls off the bottom
of the fuction with no return, because otherwise when caller pops the
stack, he will corrupt it.
>
> >>> You sound like a Jehovah's Witness.
> >>
> >> The difference is, the C standard is real.
> >
> > They're both written by humans.
> I don't really want to get into religious discussions. But you could
> read through the C standards in a day and have a pretty good idea of
> most of it, and be familiar enough to find the references you need when
> you want them. It would probably take a couple of years to reach the
> same level of familiarity with the Bible - the comparison between the
> two documents is clearly absurd.
>
The C standard really is inerrant, because we've agreed that "C" means
whatever the standard says it means. Even if it is stupid, or pig-ignorant.
>
> > 99% of the work is nothing to do with the standard. It's a slog. A lot
> > of it caused by so much diversity in all the C code out there, /because/
> > people have too much freedom to write what they like.
> >
> The standard is what defines the language. How could it not be important?
>
You can have good enough conformance. Some conforming programs written
in deliberately odd ways might compile incorrectly, but that would be a minor
defect.

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

>
> It's just a minor implementation decision. But if you choose option two,
> then callee has to push something even if control falls off the bottom
> of the fuction with no return, because otherwise when caller pops the
> stack, he will corrupt it.

That's true, which is a reason why option two is never used.

>>
>>>>> You sound like a Jehovah's Witness.
>>>>
>>>> The difference is, the C standard is real.
>>>
>>> They're both written by humans.
>> I don't really want to get into religious discussions. But you could
>> read through the C standards in a day and have a pretty good idea of
>> most of it, and be familiar enough to find the references you need when
>> you want them. It would probably take a couple of years to reach the
>> same level of familiarity with the Bible - the comparison between the
>> two documents is clearly absurd.
>>
> The C standard really is inerrant, because we've agreed that "C" means
> whatever the standard says it means. Even if it is stupid, or pig-ignorant.

Yes, that's how standards work.

>>
>>> 99% of the work is nothing to do with the standard. It's a slog. A lot
>>> of it caused by so much diversity in all the C code out there, /because/
>>> people have too much freedom to write what they like.
>>>
>> The standard is what defines the language. How could it not be important?
>>
> You can have good enough conformance. Some conforming programs written
> in deliberately odd ways might compile incorrectly, but that would be a minor
> defect.
>

A compiler does not have to be fully conformant to any given C standard,
and such compilers can be a lot more useful than standard-pedantic
compilers for some uses. Almost all my coding relies on compiler
extensions to some extent.

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

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Ergonomics experts often design interfaces that I find hard to
>>>> use. To take one example, I want to use common key binding across
>>>> applications, but the experts seem to think there is only one such
>>>> set (and it comes from an OS I have not used for years), so I
>>>> can't use the bindings my fingers "know" about.
>>>
>>> I'm curious to know more about the specifics here. What key
>>> bindings, which "one set to rule them all", what domain of
>>> applications followed that set?
>>
>> I like to use Emacs keybindings. I can use them in bash and programs
>> that use GNU readline which includes a lot of REPL programs like ghci,
>> swipl, gp and so on. I can't use them in the Gnome browser.
>
> Clearly emacs needs to add M-x new-browser-frame .

:-)

> By the way, have you tried the Brave browser?

Because you mentioned it, just now. It's exactly like chrome but with
various blockers and some pestering about a rewards scheme. I'll keep
it for a while to see what I think.

>> One big annoyance is not strictly to do with keys but is UI-related. I
>> am used to having selected text available for immediate pasting with the
>> middle button, but several applications have started to auto select text
>> in certain situations and I loose my selection.
>
> Clearly a need for selection rings so ESC <middle button> would
> paste the second most recent selection, etc.
>
> More seriously, one-level-deep "clipboards" really bug me. I
> know one is a lot lot better than zero, but even just two or
> three would be a lot better than one.

Yes. But I'd still prefer it if applications did not clobber my
selection. I run Gpaste to give me a full selection history, but I'd
rather not have to use it at all.

--
Ben.

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". The stack
is purely conventional, it doesn't mean anything at the silicon level.
"Jump and link" places the current program counter in a designated
register, then jumps to an address. 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.
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.

On 06/09/2023 15:08, David Brown wrote:
> On 05/09/2023 23:05, Bart wrote:

>> So my main disagreement is with the Optional return of non-void
>> functions (which I've now given up on), and how seriously
>> infringements of those 'N' cases are reported.
>
> Just to be clear here - and I /really/ hope you will answer this one
> simply and unambiguously - do you understand that the C standards make
> the return statement optional?

I understand they were obliged to do so for historical reasons.

I also understand that a compiler can choose to make it compulsory for
non-void functions.

> rule out misuse (you are not allowed to attempt to use the value of
> falling off the end of a non-void function),

But you very easily can. Whereas in my language, it is not possible.

> This all follows a common pattern for C - the standards define what
> useful and meaningful code does, but do not attempt to enforce good
> programming practice, since that varies hugely for different use-cases.
> It is up to tools to aid users in their development, not the C language.
>  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.  And the preferences for different
> programmers vary wildly.  Since most tools are targeted at many
> different people and coding styles, they support options to let users
> decide what they need.  Other tools are more specialised - specific
> checkers for the Linux kernel, MISRA rule checkers for the automotive
> industry, and so on.

MISRA tries to tame the wild possibilities of C, and suggests not using
features that are troublesome or error prone.

A lot of the problems with implementing C (see my other comments below)
are because so much diversity as been allowed, and rarely deprecated.

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

In my new C compiler, this function:

char* getversion(void) {
return "0.99";
}

generates this IR for a stack-based virtual machine:

getversion:
load "0.99"
jump #4 (optimised out later)
#4:
retfn

'load' actually means 'push' (to avoid endless confusion with hardware
'push' instructions of the target).

So something is expected on the virtual stack. If that return statement
is commented out, it generates:

getversion:
retfn

The stacked return value is missing. This eventully gets turned into
register-based code, but that there is a missing operand will cause an
issue.

One of my languages generates a discrete IL that is an actual
independent language. The equivalent program /with/ the return produces
this:

proc $t.getversion
rettype u64
loadimm u64 "0.99.1"
return
end

Again, 'loadimm' pushes a value. I can run this via a separate
interpreter which uses an actual stack. If I comment out that 'loadimm'
line (as I can't do it in the HLL), it won't crash (it's an interpreter)
but it detects an error and aborts, as the instruction pointer gets
screwed up.

It's a bigger deal than you're making out. C is supposed to run on a
wide range of architectures - but not if they are stack-based?

>> 99% of the work is nothing to do with the standard. It's a slog. A lot
>> of it caused by so much diversity in all the C code out there,
>> /because/ people have too much freedom to write what they like.
>>
>
> The standard is what defines the language.  How could it not be important?

Anyone who tries to implement C will know most of C. They might use the
grammar in the standard to design their lexers and parsers around. That
is the easy bit. (I notice it gives very little guidance regarding the
preprocessor: I have seen a 100-page reference which goes into a lot
more detail. But I came across it years too late.)

Most of it is the usual palaver of writing compilers: type-checking,
generating code, providing standard headers, maybe a library, plus, for
C, one more thing: making it work with billions of lines of existing code.

Code that flouts every rule in the book. That dwarfs everything else,
can take many years, and might never end.

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.

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.

>>> 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. Most authors will
invent a notation for a configuration (often a pictorial one) to help in
explanations.

--
Ben.

On 06/09/2023 19:13, Bart wrote:
> On 06/09/2023 15:08, David Brown wrote:
>> On 05/09/2023 23:05, Bart wrote:
>
>>> So my main disagreement is with the Optional return of non-void
>>> functions (which I've now given up on), and how seriously
>>> infringements of those 'N' cases are reported.
>>
>> Just to be clear here - and I /really/ hope you will answer this one
>> simply and unambiguously - do you understand that the C standards make
>> the return statement optional?
>
> I understand they were obliged to do so for historical reasons.

So that's a yes?

(I think "historical reasons" are likely a major reason for this, but I
don't think that is the whole story.)

>
> I also understand that a compiler can choose to make it compulsory for
> non-void functions.

If the compiler is not trying to implement standard C, then yes, that is
the case. A conformant compiler, however, must accept code that follows
the syntax and constraint rules of the language and has well-defined
meaning - and non-void functions without return statements can be part
of such code. (It can warn about the potential problems of such code,
while remaining conformant - but it must accept the code and generate
appropriate object code.)

>
>> rule out misuse (you are not allowed to attempt to use the value of
>> falling off the end of a non-void function),
>
> But you very easily can. Whereas in my language, it is not possible.

In your language, just as in any language, misuse - bugs - are not
difficult to write. To be clear, I am all in favour of stricter
languages and minimising the risk of accidental errors in code (that's
why I use a strict subset of C in my C coding). And if I were creating
a new language, I would not allow the possibility of running of the end
of a non-void function. (Functions which do not return at all would not
need an artificial return statement.) But in reality, the chances of
accidentally introducing such a missing return bug in C code are
extremely small - you need not only to write the bad code, but you also
need to be incompetent at basic software development practices (such as
using static checking).

>
>> This all follows a common pattern for C - the standards define what
>> useful and meaningful code does, but do not attempt to enforce good
>> programming practice, since that varies hugely for different
>> use-cases. It is up to tools to aid users in their development, not
>> the C language.   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.  And the preferences for
>> different programmers vary wildly.  Since most tools are targeted at
>> many different people and coding styles, they support options to let
>> users decide what they need.  Other tools are more specialised -
>> specific checkers for the Linux kernel, MISRA rule checkers for the
>> automotive industry, and so on.
>
> MISRA tries to tame the wild possibilities of C, and suggests not using
> features that are troublesome or error prone.
>

That's roughly correct, in theory. In practice, some of the rules in
MISRA are good ideas, many are blindingly obvious to anyone qualified to
write code, some are based on mixed up misunderstandings of C and will
get you in trouble if you follow MISRA's advice, and some are downright
bad practice that lead to worse code and a higher risk of errors. I am
not at all a fan of MISRA - it's as much about legal arse-covering as
writing safer software.

But of course it is a good idea to limit the way you write your C code,
for many reasons.

> A lot of the problems with implementing C (see my other comments below)
> are because so much diversity as been allowed, and rarely deprecated.
>

I don't see that as a major problem for implementing C, although I can
well imagine some things would be easier (such as the preprocessor) if
there had been a little less flexibility. It can be a problem when
dealing with C code, however - C is sometimes written in a way that is
very difficult to follow.

>>> 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.
>
>
> In my new C compiler, this function:
>
>   char* getversion(void) {
>       return "0.99";
>   }
>
> generates this IR for a stack-based virtual machine:
>
>   getversion:
>      load  "0.99"
>      jump #4                   (optimised out later)
>   #4:
>      retfn
>
> 'load' actually means 'push' (to avoid endless confusion with hardware
> 'push' instructions of the target).

OK.

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

I would suggest that a better IR would give :

getversion :
move return_reg, "0.99"
ret

If the C "return" statement is commented out, you just have :

getversion :
ret

The returned value is always returned in the register "return_reg". If
the function doesn't have a "return expr" statement, it will not put
anything into that register - it contains old, invalid or random data.
This is not a problem if the calling code does not use it.

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.

>
> The stacked return value is missing. This eventully gets turned into
> register-based code, but that there is a missing operand will cause an
> issue.
>
> One of my languages generates a discrete IL that is an actual
> independent language. The equivalent program /with/ the return produces
> this:
>
>   proc $t.getversion
>     rettype  u64
>     loadimm  u64   "0.99.1"
>     return
>   end
>
> Again, 'loadimm' pushes a value. I can run this via a separate
> interpreter which uses an actual stack. If I comment out that 'loadimm'
> line (as I can't do it in the HLL), it won't crash (it's an interpreter)
> but it detects an error and aborts, as the instruction pointer gets
> screwed up.
>
> It's a bigger deal than you're making out. C is supposed to run on a
> wide range of architectures - but not if they are stack-based?

As I showed above, this is not a problem unless you have actively chosen
to make it a problem. But you do need to make your IR fit the language
as it is defined.

>
>>> 99% of the work is nothing to do with the standard. It's a slog. A
>>> lot of it caused by so much diversity in all the C code out there,
>>> /because/ people have too much freedom to write what they like.
>>>
>>
>> The standard is what defines the language.  How could it not be
>> important?
>
> Anyone who tries to implement C will know most of C. They might use the
> grammar in the standard to design their lexers and parsers around. That
> is the easy bit. (I notice it gives very little guidance regarding the
> preprocessor: I have seen a 100-page reference which goes into a lot
> more detail. But I came across it years too late.)

The details in the C standard are a bit terse, and they are certainly
not designed as a tutorial on implementing a preprocessor (or C
compiler) - they are not even intended as a tutorial on using the
language. But they are, to my knowledge, complete.

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.