On 07/09/2023 22:36, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I've already suggested a compiler should return all-zeros as a default
>> return value for code that runs into the final '}'. That will provide
>> a consistent return value.
>
> That could mask bugs.
>
> int func(void) {
> if (this) {
> return a_value;
> }
> else if (that) {
> return another_value;
> }
> else if (the_other) {
> return yet_another_value;
> }
> }
>
> Perhaps I simply forgot to write a return statement at the end, either
> before the closing } or in an else clause. Currently, a compiler is not
> required to diagnose this, but many will warn about it with the right
> options. If the language stated that falling off the end implicitly
> returns "all-zeros" (I won't get into what that means), then the behavior
> is well defined and the compiler is unlikely to be able to help.
>

My bcc compiler would report a missing return value on that, unless you
give it the option to pass such code.

In /that/ case, supplying a zero value if the function does actually
fall off the end is preferable. This is exactly what happens with main().

It needn't affect how such things need to be reported.

As for what all-zeros means, it will be something all 0, 0.0 or NULL for
scalar types, and all-bits-zero for small aggregates passed in registers.

For larger aggregates passed in memory, the result of applying
memset(addr, 0, size). But I'm sure you will have guessed this.

(I'm not getting into architectures where ints, floats and pointers have
other representations than all-bits-size for zero or null. Ask the
people who devised them.)

Bart <bc@freeuk.com> writes:
[...]
> Yes, in main(), it ensures the return value is 0, instead of being
> undefined. But it's not bothered about that for fred(), although it
> could have done the same.
>
> Why the special dispensation for main(), and not for user functions?
> And don't say because the Standard stipulates; it could have
> stipulated for user functions too!

The rule is that "reaching the } that terminates the main function
returns a value of 0". This applies only if main is defined with a
return type of int (an implementation may permit other return types).
It applies only to hosted implementations. This was introduced in
C99, borrowed from C++; in C90, falling off the end of main would
return an undefined result.

I was never happy about this rule. It's an unnecessary special case.
But it doesn't break any existing code, and gives meaning to some code
that previously returned an undefined result -- a meaning that is very
probably what was intended. For example, the "hello, world" program in
K&R2 has no return statement. I accept the rule and sometimes take
advantage of it (since I don't worry about pre-C99 compilers).

The reasons for *not* doing this for functions other than main seem
fairly obvious to me. The main() function is unique. A return value
of 0 from main has a language-defined meaning: it indicates that the
program terminated successfully. No other user-defined function has
a language-defined meaning for any returned value. Semantically,
the main() function almost always does things that have side effects.
Other functions are more commonly called primarily for their return
values, and letting the language assign an arbitrary default return
value that may or may not have a meaning would be a bad idea.

Finally, this function:

int absolute_value(int n) {
if (n < 0) return -n;
}

has a bug. A compiler is not required to diagnose it but many (most?)
compilers will warn about it with the right options. If reaching the
closing } implicitly returned 0, a compiler would have no basis to warn
about a missing return value.

--
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 07/09/2023 23:16, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:

> Finally, this function:
>
> int absolute_value(int n) {
> if (n < 0) return -n;
> }
>
> has a bug. A compiler is not required to diagnose it but many (most?)
> compilers will warn about it with the right options. If reaching the
> closing } implicitly returned 0, a compiler would have no basis to warn
> about a missing return value.
>

I said: "It needn't affect how such things need to be reported."

Implicitly returning 0 doesn't affect diagnostics.

But if people choose to ignore warnings, or choose not to see warnings,
then if the function runs into }, it will consistently return 0.

In this example, that happens to be the wrong result for most positive
values of n, and the bug is obvious. By not returning zero, it is quite
likely it will return the correct result: the value of a positive n
which happens to be loaded into the register used to return a value.

You will not suspect a bug. But on another machine/compiler/set of
options (where maybe n is tested in memory, or resides in a different
register), it will go wrong.

So returning zero makes the bug more obvious in this case.

As it happens, if I run this program:

#include <stdio.h>

int absolute_value(int n) {
if (n<0) return -n;
}

int main(void) {
printf("%d\n", absolute_value(123));
}

Both bcc-old and tcc show '123'. But 'gcc -std=c11 -Wpedantic', which
reports no diagnostic, shows -1887184072. With -O1/2/3, it shows 0.

gcc-O0 on rextester.com with showed -2019228064. Clang-O2 there showed
-123, and Clang-O0 was 0.

bcc without -old gives a hard error.

Which would be better: some random choice of one of these values when n>=0:

123 # the right answer!
-1887184072
0
-2019228064
-123

or consistently this:

0

Bart <bc@freeuk.com> writes:
[...]
> OK, up to the last 4.x.y gcc version, both functions generate only:
>
> rep ret
>
> for their bodies. That is, just two bytes of code. The rest of what
> you posted above is just whatever garbage happened to follow.
>
> From gcc 5.1 upwards, main includes code to zero eax before returning.

Yes, and that's completely unsurprising once you look at the history.

The rule that falling off the end of main implicitly returns 0 was added
in C99. In C90, the return status is undefined. (On various systems,
I've seen 0, 1, and 41.)

All gcc-4.* versions default to "-std=gnu89" or "-std=gnu90" if no
standard is specified.

All gcc-5.* versions default to "-std=gnu11" if no standard is specified.

I expect that "gcc-4 -std=gnu90" and "gcc-5 -std=gnu90" will behave the
same way with respect to falling off the end of main (generating code
that returns an arbitrary status).

I expect that "gcc-4 -std=gnu99" and "gcc-5 -std=gnu99" will behave the
same way with respect to falling off the end of main (generating code
that returns a status of 0).

[...]

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

Which is exactly the behavior I want and expect.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> If there's a point at all there, it is that gcc is broken when it
> generates an implicit return value of success (zero), in my opinion.

That behavior is explicitly required (for main, and only for main) by
the ISO C standard starting in C99. See 5.1.2.2.3p1.

--
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:
[...]
> As for what all-zeros means, it will be something all 0, 0.0 or NULL
> for scalar types, and all-bits-zero for small aggregates passed in
> registers.
>
> For larger aggregates passed in memory, the result of applying
> memset(addr, 0, size). But I'm sure you will have guessed this.

Since I oppose adding a rule to do an implicit return on non-void
functions other than main, I didn't spend much time considering what you
meant by "all-zeros". I'm not surprised that you meant all-bits-zero.

If such a rule were added, "all-zeros" should follow the same rules as
for static objects with no explicit initialization. That means 0 for
integer types, 0.0 for floating-point types, null for pointer types, and
recursively for array, structure, and union types. On many systems,
that happens to be all-bits-zero, which is convenient.

Such a value can be specified as a compound literal: `(return_type){0}`.
(C23 will allow the 0 to be omitted.)

> (I'm not getting into architectures where ints, floats and pointers
> have other representations than all-bits-size for zero or null. Ask
> the people who devised them.)

The C standard must consider such architectures, and it does so by
specifying rules that do not assume the meaning of all-bits-zero (other
than for integer types). It would be silly to add a new requirement for
values implicitly returned from functions that simply specified
all-bits-zero. And again, I oppose any requirement to specify an
implicit return value.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Bart <bc@freeuk.com> writes:
> On 07/09/2023 23:16, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>> Finally, this function:
>> int absolute_value(int n) {
>> if (n < 0) return -n;
>> }
>> has a bug. A compiler is not required to diagnose it but many
>> (most?)
>> compilers will warn about it with the right options. If reaching the
>> closing } implicitly returned 0, a compiler would have no basis to warn
>> about a missing return value.
>
> I said: "It needn't affect how such things need to be reported."
>
> Implicitly returning 0 doesn't affect diagnostics.

It should.

Suppose C29 adds a rule that reaching the closing } of an int function
does an implicit `return 0;`. (I'm restricting it to int for now just
for simplicity; presumably it would apply to all non-void functions.)

Then this:

int sign(int n) {
if (n < 0) return -1;
if (n > 0) return +1;
}

is a perfectly valid C29 implementation of a sign() function.
It correctly returns -1 for a negatve argument, +1 for a positive
argument, and 0 for a zero argument.

Are you suggesting that a C29 compiler would still be required
to issue a warning? If not, are you suggesting that a "good"
C compiler *should* issue a warning? For code that conforms to
the C29 standard, with completely defined behavior?

C already says that reaching the end of main implicitly returns 0.
Should a compiler warn about a program that takes advantage of that?
Should a conforming compiler be *required* to do so?

The C standard does not require non-fatal warnings (except for a
#warning directive, new in C23). A conforming compiler can treat
every violation of a syntax rule or constraint as a fatal error,
and not issue any other diagnostics.

> But if people choose to ignore warnings, or choose not to see
> warnings, then if the function runs into }, it will consistently
> return 0.
>
> In this example, that happens to be the wrong result for most positive
> values of n, and the bug is obvious. By not returning zero, it is
> quite likely it will return the correct result: the value of a
> positive n which happens to be loaded into the register used to return
> a value.
>
> You will not suspect a bug. But on another machine/compiler/set of
> options (where maybe n is tested in memory, or resides in a different
> register), it will go wrong.
>
> So returning zero makes the bug more obvious in this case.

Returning zero hides the bug if zero is a likely correct result.

Suppose a function returns zero on success, non-zero on failure (a
common convention in some contexts). Implicitly returning zero will
hide bugs.

> As it happens, if I run this program:
[snip]
> Which would be better: some random choice of one of these values when n>=0:
>
> 123 # the right answer!
> -1887184072
> 0
> -2019228064
> -123
>
> or consistently this:
>
> 0

Arbitrary and varying results give you a better chance of diagnosing the
error. Some compilers, in debug mode, set uninitialized memory to some
recognizable pattern that's unlikely to be valid; your proposed rule
would make that illegal.

Diagnosing the failure to return a value at compile time is ideal. It's
not possible to diagnose it perfectly, but many compilers can be made to
do a decent job. "gcc -Wall" warns "control reaches end of non-void
function" for your sample program (which I snipped in this followup).

--
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 2023-09-07, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I've already suggested a compiler should return all-zeros as a default
>> return value for code that runs into the final '}'. That will provide
>> a consistent return value.
>
> That could mask bugs.

If that were an additional step accompanying a well-designed warning, it
would be acceptable. The developer was warned, and the program and its
user are protected from nondeterministic behavior.

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

But imagine if C had always been like this. Suppose you've been programming
for many years with the backgorund assummption that as soon as you write
an empty function like

int func(void) {
}

you have something that returns zero; you learned it that way from the
start.

Then you're always aware of this and keep it in mind.

"I'm writing various cases that return nonzero, otherwise fall through
to the usual zero."

You might already put a unit test for that empty function before
adding the other cases.

The only reason I might write func as you have it above is not that
I forgot that the function must return a value in all cases, but
that I planned to do that, but got distracted.

With the return zero, I will still have the same thought of planning to
return something in all cases. The difference is that I cannot get
distracted away such that I lose the zero default.

I can get still get distracted in such a way that I forget to write a
few needed cases that must return nonzero.

That problem, however, exists even if I start with this:

int func(void) {
return 0;
}

and then add cases above the return.

I work with Lisp dialect in which there is always a return value,
defaulting to nil (loosely speaking). This is very pleasant to work
with. I have a sense that it fixes more issues than it causes; I've
not had occasion to curse at the mechanism as the cause of a problem.

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

On 05/09/2023 19:06, Bart wrote:
> On 05/09/2023 16:31, David Brown wrote
....
>> Is there some reason that you won't look at the standard here?
>
> Yes, it's like someone asking me to check the Bible to see for myself
> whether it mentions something or not. But it's quite a big book, and
> maybe I'd have to collate slightly different quites in different places.
> And maybe I'd end up looking in the wrong place.

Why would there be any danger of that? You've been given, and have
ignored, citations identifying precisely the locations that you should
look at. Since you did ignore them, you probably don't even remember
receiving those citations - but that's your problem.

On Thursday, 7 September 2023 at 22:52:07 UTC+1, Keith Thompson wrote:
> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
> > David Brown <david...@hesbynett.no> writes:
> >> With C11, you can write :
> >>
> >> _Noreturn void abort_with_error_message(const char *);
> >>
> >> So you don't have to wait until C23 (unless you really want the attribute
> >> syntax).
> >
> > I somehow missed that in C11. Thanks.
> C11 added the _Noreturn keyword and the <stdnoreturn.h> header, which
> defines a macro `noreturn` that expands to `_Noreturn`.
>
> C23 makes all that obsolescent, and introduces attributes, including
> [[noreturn]].
>
Exactly. You use the whizzy new feature, and in the next version of the
compiler it is obsolete. Typical.

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

When writing that post, I first thought _Noreturn was from C17 - I had
to look it up to see it was in C11.

(Many of these kinds of things are standardisations of extensions in gcc
and clang - and since my code normally does not have to be portable
beyond gcc, I have been using things like "__attribute__((noreturn))"
since long before C11.)

On 08/09/2023 09:46, Malcolm McLean wrote:
> On Thursday, 7 September 2023 at 22:52:07 UTC+1, Keith Thompson wrote:
>> Ben Bacarisse <ben.u...@bsb.me.uk> writes:
>>> David Brown <david...@hesbynett.no> writes:
>>>> With C11, you can write :
>>>>
>>>> _Noreturn void abort_with_error_message(const char *);
>>>>
>>>> So you don't have to wait until C23 (unless you really want the attribute
>>>> syntax).
>>>
>>> I somehow missed that in C11. Thanks.
>> C11 added the _Noreturn keyword and the <stdnoreturn.h> header, which
>> defines a macro `noreturn` that expands to `_Noreturn`.
>>
>> C23 makes all that obsolescent, and introduces attributes, including
>> [[noreturn]].
>>
> Exactly. You use the whizzy new feature, and in the next version of the
> compiler it is obsolete. Typical.

"obsolescent" does not mean "obsolete". It means that the feature
might, in the future, be a likely candidate for being made "obsolete".
Thus function declarations of the form "int foo();" meaning "foo make
take some parameters, but I'm not saying how many or what type" have
been "obsolescent" since C90 (after function prototypes were
introduced). But they were not "obsolete" until C23, when the meaning
was changed to be the same as "int foo(void);", just like in C++.

The C standards committee has taken the decision (for better or worse -
I'm sure opinions will vary) that [[attribute]] syntax is an important
feature going forward, and that it gives a flexible and convenient
structure for new features in the future. In particular, it means
things like "_Noreturn" can be added to the language without needing new
keywords, without conflicting with user identifiers, without needing
awkward _Reserved naming style, and without adding new standard headers
that exist only to provide neater names.

Marking "_Noreturn" (and <stdnoreturn.h>) as "obsolescent" and replaced
by "[[noreturn]]" is just an indication that the attribute style is what
the C committee sees as becoming standard practice in the future, and
code written to C23 should move to that practice for consistency.

So "_Noreturn" will probably be supported for the next 33 years before
being actually "obsolete". And even then, you will be able to define a
macro "#define _Noreturn [[noreturn]]".

On 07/09/2023 16:55, Bart wrote:
> On 07/09/2023 15:28, Ben Bacarisse wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>>> Do you have in mind examples of situations in which false positives
>>> would cause problems, or even just irk the programmer?
>>
>> Well I'd be irked by having to write a 'return 0;' there just to shut
>> the compiler up.  But, to be clear, it's a tiny irk.
>
> Having to do so at the end of main() must have irked enough people that
> most C compilers allow it to be left out.
>
> But, in the case of main, they also do something special; for this program:
>
>   int fred(void) {}
>   int main(void) {}
>
<snip>
>
> Yes, in main(), it ensures the return value is 0, instead of being
> undefined. But it's not bothered about that for fred(), although it
> could have done the same.
>
> Why the special dispensation for main(), and not for user functions? And
> don't say because the Standard stipulates; it could have stipulated for
> user functions too!
>

It doesn't matter what the standard /could/ have stipulated - it only
matters what it /does/ stipulate.

But the answer, as is usually the case for such oddities in C, is "for
historical reasons".

(In many systems, the C language and C compiler has very little control
about how "main" is called, and what happens when "main" returns. This
is different from all other user functions.)

On 08/09/2023 10:16, David Brown wrote:
> On 07/09/2023 16:55, Bart wrote:
>> On 07/09/2023 15:28, Ben Bacarisse wrote:
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>>> Do you have in mind examples of situations in which false positives
>>>> would cause problems, or even just irk the programmer?
>>>
>>> Well I'd be irked by having to write a 'return 0;' there just to shut
>>> the compiler up.  But, to be clear, it's a tiny irk.
>>
>> Having to do so at the end of main() must have irked enough people
>> that most C compilers allow it to be left out.
>>
>> But, in the case of main, they also do something special; for this
>> program:
>>
>>    int fred(void) {}
>>    int main(void) {}
>>
> <snip>
>>
>> Yes, in main(), it ensures the return value is 0, instead of being
>> undefined. But it's not bothered about that for fred(), although it
>> could have done the same.
>>
>> Why the special dispensation for main(), and not for user functions?
>> And don't say because the Standard stipulates; it could have
>> stipulated for user functions too!
>>
>
> It doesn't matter what the standard /could/ have stipulated - it only
> matters what it /does/ stipulate.
>
> But the answer, as is usually the case for such oddities in C, is "for
> historical reasons".
>
> (In many systems, the C language and C compiler has very little control
> about how "main" is called, and what happens when "main" returns.  This
> is different from all other user functions.)

The internal details don't matter to the user. The way main() is defined
and used should be identical to any other function.

Actually, on Windows, the existence of a function like this is an illusion:

int main(int n, char** args) {}

The entry point to a program in any language doesn't provide those two
(or sometimes three) arguments already set up, as it probably does on Linux.

It has to be emulated.

On 08/09/2023 11:51, Bart wrote:
> On 08/09/2023 10:16, David Brown wrote:
>> On 07/09/2023 16:55, Bart wrote:
>>> On 07/09/2023 15:28, Ben Bacarisse wrote:
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>
>>>>> Do you have in mind examples of situations in which false positives
>>>>> would cause problems, or even just irk the programmer?
>>>>
>>>> Well I'd be irked by having to write a 'return 0;' there just to shut
>>>> the compiler up.  But, to be clear, it's a tiny irk.
>>>
>>> Having to do so at the end of main() must have irked enough people
>>> that most C compilers allow it to be left out.
>>>
>>> But, in the case of main, they also do something special; for this
>>> program:
>>>
>>>    int fred(void) {}
>>>    int main(void) {}
>>>
>> <snip>
>>>
>>> Yes, in main(), it ensures the return value is 0, instead of being
>>> undefined. But it's not bothered about that for fred(), although it
>>> could have done the same.
>>>
>>> Why the special dispensation for main(), and not for user functions?
>>> And don't say because the Standard stipulates; it could have
>>> stipulated for user functions too!
>>>
>>
>> It doesn't matter what the standard /could/ have stipulated - it only
>> matters what it /does/ stipulate.
>>
>> But the answer, as is usually the case for such oddities in C, is "for
>> historical reasons".
>>
>> (In many systems, the C language and C compiler has very little
>> control about how "main" is called, and what happens when "main"
>> returns.  This is different from all other user functions.)
>
> The internal details don't matter to the user. The way main() is defined
> and used should be identical to any other function.

I too would prefer consistency here - I see no reason why falling off
the end of main() should act as "return 0;", except to standardise
existing old practice.

However, the way main() is defined and used is /not/ identical to other
functions - it is special in some ways, because it is the starting point
for a C program, and leaving the initial call to the function is the end
of the program. The ways you can declare it is also pre-determined,
unlike for any other user function. The effect of exiting main() is
different for the initial call, and any recursive calls. All in all,
main() is not a normal function - having it implicitly return 0 is just
one small part of that.

<https://en.cppreference.com/w/c/language/main_function>

(For fun, click the link at the bottom to look at main() in C++. It has
even more restrictions.)

>
> Actually, on Windows, the existence of a function like this is an illusion:
>
>    int main(int n, char** args) {}
>
> The entry point to a program in any language doesn't provide those two
> (or sometimes three) arguments already set up, as it probably does on
> Linux.
>
> It has to be emulated.
>

I would think this depends on the C runtime library, which is part of
the C implementation. Hosted environments are required to provide the
"program parameters" in argc and argv - that is mandated by the
standard. However, it is entirely up to the environment to say what the
"program parameters" are. And a Windows C implementation could choose
to say there are never any parameters - "argc" is always 0, while "argv"
is a pointer such that "argv[argc]" is a null pointer. That's
sufficient to fulfil the requirements. There is no C standard rule
saying that it has to be command-line parameters.

(For freestanding implementations - such as bare-metal embedded systems,
you don't even have to have a "main()" function. Sometimes another name
is used for the main function, or there is support for functions run
before main() starts. And in most embedded systems, argc will be 0 and
argv will have a single null pointer entry, though you usually just use
"int main(void)".)

Bart <bc@freeuk.com> writes:
[...]
> Actually, on Windows, the existence of a function like this is an illusion:
>
> int main(int n, char** args) {}
>
> The entry point to a program in any language doesn't provide those two
> (or sometimes three) arguments already set up, as it probably does on
> Linux.
>
> It has to be emulated.

We're talking about software. It's *all* an illusion.

--
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 08/09/2023 12:00, David Brown wrote:
> On 08/09/2023 11:51, Bart wrote:

>> Actually, on Windows, the existence of a function like this is an
>> illusion:
>>
>>     int main(int n, char** args) {}
>>
>> The entry point to a program in any language doesn't provide those two
>> (or sometimes three) arguments already set up, as it probably does on
>> Linux.
>>
>> It has to be emulated.
>>
>
> I would think this depends on the C runtime library, which is part of
> the C implementation.  Hosted environments are required to provide the
> "program parameters" in argc and argv - that is mandated by the
> standard.

The Windows hosted environment knows nothing at all about argc and argv,
and provides no such parameters.

At the entry point to an EXE programs, only a stack has been set up, and
the stack contains the return address. (However I never use that; my
main() functions in either language end in a call to exit().)

The C parameters argc and argv can be obtained with calling
__getmainargs() from msvcrt.dll. Or can be manually parsed by called the
WinAPI function GetCommandLine().

  However, it is entirely up to the environment to say what the
> "program parameters" are.  And a Windows C implementation could choose
> to say there are never any parameters - "argc" is always 0, while "argv"
> is a pointer such that "argv[argc]" is a null pointer.  That's
> sufficient to fulfil the requirements.  There is no C standard rule
> saying that it has to be command-line parameters.

As I said, those don't exist at all. They are just a C artefact. In
Linux, where there isn't really a clear demarcation between OS, and the
C language, headers, compilers and runtime, I expect the OS will provide
those arguments to the entry point of a program in any language.

On 08/09/2023 13:03, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Actually, on Windows, the existence of a function like this is an illusion:
>>
>> int main(int n, char** args) {}
>>
>> The entry point to a program in any language doesn't provide those two
>> (or sometimes three) arguments already set up, as it probably does on
>> Linux.
>>
>> It has to be emulated.
>
> We're talking about software. It's *all* an illusion.
>

Huh?

My point is that on Linux, the arguments are set up, ready to use, on
the actual entry point to your program.

On Windows, they're not.

If you're an implementer, then on Windows you have to make arrangements
so that it looks like the OS does indeed provide those arguments.

It might involve adding extra calls inside a main() which is compiled
with no parameters, or renaming the user's main to '$main', say, and
using a new main(void) which calls $main(n, args).

You might think this is a small matter, since /somebody/ has to write
code to obtain that information, and you don't care if it is somebody
implementing the C language, or implementing the OS leader.

*I* care because it's my responsibility to do it.

I am also somewhat annoyed when people assume that every OS gives the C
language, among all others, special dispensation in kindly providing C's
argc and argv to all programs, regardless of what language they happen
to be written in.

That only happens on Linux and related OSes.

On 9/8/23 07:39, Bart wrote:
> On 08/09/2023 13:03, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Actually, on Windows, the existence of a function like this is an
>>> illusion:
>>>
>>>     int main(int n, char** args) {}
>>>
>>> The entry point to a program in any language doesn't provide those two
>>> (or sometimes three) arguments already set up, as it probably does on
>>> Linux.
>>>
>>> It has to be emulated.
>>
>> We're talking about software.  It's *all* an illusion.
>>
>
> Huh?
>
> My point is that on Linux, the arguments are set up, ready to use, on
> the actual entry point to your program.
>
> On Windows, they're not.
>
> If you're an implementer, then on Windows you have to make arrangements
> so that it looks like the OS does indeed provide those arguments.
>
> It might involve adding extra calls inside a main() which is compiled
> with no parameters, or renaming the user's main to '$main', say, and
> using a new main(void) which calls $main(n, args).
>
> You might think this is a small matter, since /somebody/ has to write
> code to obtain that information, and you don't care if it is somebody
> implementing the C language, or implementing the OS leader.
>
> *I* care because it's my responsibility to do it.
>
> I am also somewhat annoyed when people assume that every OS gives the C
> language, among all others, special dispensation in kindly providing C's
> argc and argv to all programs, regardless of what language they happen
> to be written in.
>
> That only happens on Linux and related OSes.
>

The magic of standards is that you don't need to worry about the
underlying os messiness. With that said, I didn't know about the
arguments issue, that's neat.

--
--
user <candycane> is generated from /dev/urandom

On 08/09/2023 14:05, Bart wrote:
> On 08/09/2023 12:00, David Brown wrote:
>> On 08/09/2023 11:51, Bart wrote:
>
>>> Actually, on Windows, the existence of a function like this is an
>>> illusion:
>>>
>>>     int main(int n, char** args) {}
>>>
>>> The entry point to a program in any language doesn't provide those
>>> two (or sometimes three) arguments already set up, as it probably
>>> does on Linux.
>>>
>>> It has to be emulated.
>>>
>>
>> I would think this depends on the C runtime library, which is part of
>> the C implementation.  Hosted environments are required to provide the
>> "program parameters" in argc and argv - that is mandated by the standard.
>
> The Windows hosted environment knows nothing at all about argc and argv,
> and provides no such parameters.

If it is a C compiler, then it /must/ do so. It can, as I said, fix
argc at 0 and argv as a pointer to a null pointer. But it must provide
at least these if it is a C compiler.

It can allow other implementation-defined options as well.

>
> At the entry point to an EXE programs, only a stack has been set up, and
> the stack contains the return address. (However I never use that; my
> main() functions in either language end in a call to exit().)
>
> The C parameters argc and argv can be obtained with calling
> __getmainargs() from msvcrt.dll. Or can be manually parsed by called the
> WinAPI function GetCommandLine().
>

It's allowable to provide such functions as a way to get the actual
program parameters. It's a stupid design contrary to common behaviour
and expectations, but it is allowed. (Providing extra functions to get
the parameters in different ways - different character encodings,
different wildcard treatment, etc., is absolutely fine.)

>   However, it is entirely up to the environment to say what the
>> "program parameters" are.  And a Windows C implementation could choose
>> to say there are never any parameters - "argc" is always 0, while
>> "argv" is a pointer such that "argv[argc]" is a null pointer.  That's
>> sufficient to fulfil the requirements.  There is no C standard rule
>> saying that it has to be command-line parameters.
>
> As I said, those don't exist at all. They are just a C artefact.

We are talking about C. Call this a "C artefact" if you like, though I
don't really know what you mean (many other languages have a similar
system). A hosted C implementation has to support "main" as described
in the standard.

> In
> Linux, where there isn't really a clear demarcation between OS, and the
> C language, headers, compilers and runtime, I expect the OS will provide
> those arguments to the entry point of a program in any language.
>

Of course there are very clear distinctions here - except in your own
misunderstandings.

On 08/09/2023 14:39, Bart wrote:
> On 08/09/2023 13:03, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Actually, on Windows, the existence of a function like this is an
>>> illusion:
>>>
>>>     int main(int n, char** args) {}
>>>
>>> The entry point to a program in any language doesn't provide those two
>>> (or sometimes three) arguments already set up, as it probably does on
>>> Linux.
>>>
>>> It has to be emulated.
>>
>> We're talking about software.  It's *all* an illusion.
>>
>
> Huh?
>
> My point is that on Linux, the arguments are set up, ready to use, on
> the actual entry point to your program.
>
> On Windows, they're not.
>
> If you're an implementer, then on Windows you have to make arrangements
> so that it looks like the OS does indeed provide those arguments.
>

Then that is your responsibility. As the C implementer, you have to
implement C - based on whatever facilities provided by the target OS.
Surely that is an obvious tautology?

> It might involve adding extra calls inside a main() which is compiled
> with no parameters, or renaming the user's main to '$main', say, and
> using a new main(void) which calls $main(n, args).
>
> You might think this is a small matter, since /somebody/ has to write
> code to obtain that information, and you don't care if it is somebody
> implementing the C language, or implementing the OS leader.
>
> *I* care because it's my responsibility to do it.

Exactly - it is /your/ responsibility. Don't shirk it.

You can complain to the twats that wrote the OS that you use, if you
like. Or you can put the calls to "get_commandline_args" (or whatever
it is) in your C runtime startup code that runs before calling main().
That's what other implementers do.

You can lookup the startup code for glibc or newlib on Linux, and you'll
see that although these parameters are on the stack when the code jumps
to "_start", they must be taken off the stack and arranged correctly
according to the C ABI before calling main().

Writing a Windows C startup might be more difficult - call the
"get_commandline_args" functions, transform them into standard formats,
and pass the results on to main. You know how to do all that.

Or be lazy (and still compliant), and do :

void _start(void) {
char * argv[] = { 0 };
exit(main(0, argv));
}

>
> I am also somewhat annoyed when people assume that every OS gives the C
> language, among all others, special dispensation in kindly providing C's
> argc and argv to all programs, regardless of what language they happen
> to be written in.

You are only annoyed because you misunderstand the situation.

It does not matter what the OS does, or how C-friendly it might be. The
job of a C implementer is to make a C implementation, for C code. Their
job in the C startup code is to take whatever the OS gives them, and
turn it into a standards-compliant call to main(). It's no different
from implementing Pascal, Rust, Ada, or any other standardised language.
People writing Ada implementations have to make sure the program
parameters are available via the Ada.Commmand_Line module, using
whatever mechanism the OS provides for getting that. They do this
without complaining that the OS is not Ada-friendly.

>
> That only happens on Linux and related OSes.
>

On 2023-09-08, David Brown <david.brown@hesbynett.no> wrote:
> On 08/09/2023 11:51, Bart wrote:
>> The internal details don't matter to the user. The way main() is defined
>> and used should be identical to any other function.
>
> I too would prefer consistency here - I see no reason why falling off
> the end of main() should act as "return 0;", except to standardise
> existing old practice.

I don't believe there was an old practice.

The practice was one of hordes of programmers being ignorant of the
concept of a termination status.

This was done in C because C++ did it.

C++ did it probably because they thought it's one more way to improve
the C subset of C++ to make a better C.

By adopting such a rule at the language level, you can fix countless
broken programs that return a pseudo-random termination status;
they just have to be recompiled with an implementation that has picked
up the rule.

I think that if C and C++ hadn't adopted this rule, we would still have
many programs out there returning garbage termination status.

Still, it's strange because C and C++ languages are not normally of the
kind that try to save the end user from programmer ignorance. In the
big picture, in which so many things can go wrong in developing a
complex application, fixing the broken return of main is a like fart in
a hurricane.

---

main is not such a different function in C. It can be a perfectly
ordinary function. What is special about it is that it can have one
of two standard type signatures.

However, that can be handled transparently in many implementations,
because it is commonly de facto safe to pass more arguments to a
function than it takes.

The ISO C <stdarg.h> feature came from something called <varargs.h>
which was entirely predicated on passing a variable number of
arguements to a function, prior to the existence of prototype
declarations and the ... ellipsis.

SowWhen it comes to C, main can be just an external function which is
linked to by the "CRT" module by name, and that module can assume that
it is int main(int, char **). (Except on implementations which have
calling conventions whereby the callee cleans up the stack and such.)

It is rather in C++ that main is more special. C++ has type safe
linkage, and so int main(void) looks different from int main(int, char
**). In actual implementations, this is done by encoding the type into
the symbol name, which is informally called "name mangling".

C++ implementations likely disable name mangling for main so
that it is more easy to link to.

In C++, main is not required to be recursively invokable; and it is
probably for that reason. The definition of main is also a declaration.
But since main is specially handled, that declaration may not actually
be suitable for calling it. That is to say, if the C++ program calls
main, that might generate a reference to the mangled name which doesn't
actually exists.

Perhaps since C++ main is already special, it was an easier decision
in C++ to put in the rule regarding the implicit return.

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

On 2023-09-08, Bart <bc@freeuk.com> wrote:
> The Windows hosted environment knows nothing at all about argc and argv,
> and provides no such parameters.

Using Microsoft's tools, Windows programs can be compiled without
an ISO C main, using a winMain function instead.

That makes the C implementation "freestanding" to some extent.

ISO C say that programs in a "conforming hosted" implementation
start with a main function.

In a freestanding implementation, the startup function is
implementation-defined. Freestanding implementations can implement
any subset of the Library. For instance in spite of main not being
the startup function, all of <stdio.h> can work fine.
>
> At the entry point to an EXE programs, only a stack has been set up, and
> the stack contains the return address. (However I never use that; my
> main() functions in either language end in a call to exit().)
>
> The C parameters argc and argv can be obtained with calling
> __getmainargs() from msvcrt.dll. Or can be manually parsed by called the
> WinAPI function GetCommandLine().
>
>   However, it is entirely up to the environment to say what the
>> "program parameters" are.  And a Windows C implementation could choose
>> to say there are never any parameters - "argc" is always 0, while "argv"
>> is a pointer such that "argv[argc]" is a null pointer.  That's
>> sufficient to fulfil the requirements.  There is no C standard rule
>> saying that it has to be command-line parameters.
>
> As I said, those don't exist at all. They are just a C artefact. In
> Linux, where there isn't really a clear demarcation between OS, and the
> C language, headers, compilers and runtime, I expect the OS will provide
> those arguments to the entry point of a program in any language.

It does, but that entry point isn't simply main.

In Linux, dynamically linked programs compiled with glibc are ELF
executables, which are "run" by the "interpreter" indicated in their
header.

Just like a script file indicates an interpreter like #!/bin/sh
or #!/usr/bin/python3, an ELF executable has a header in which a
field indicates the interpreter like /lib/ld-linux.so.2.

The kernel maps that program into memory and passes it the executable as
an argument (or perhaps an open descriptor?)

ld-linux.so.2 attaches the shared libraries which that program needs,
and performs their initialization. Only then is the entry point in
the executable invoked. That entry point isn't main(), but some
_start function or whatever. I think it's not found by symbol but
by a hard numeric offset field in the program header. That offset is
just jumped to basically.

Something like that. By the time main() is called, stuff has happened.

In C++ you can have objects at file scope which can have constructors;
those will be called before main does, and they can rely on the
library having been initialized.

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

On 2023-09-08, Bart <bc@freeuk.com> wrote:
> On 08/09/2023 13:03, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Actually, on Windows, the existence of a function like this is an illusion:
>>>
>>> int main(int n, char** args) {}
>>>
>>> The entry point to a program in any language doesn't provide those two
>>> (or sometimes three) arguments already set up, as it probably does on
>>> Linux.
>>>
>>> It has to be emulated.
>>
>> We're talking about software. It's *all* an illusion.
>>
>
> Huh?
>
> My point is that on Linux, the arguments are set up, ready to use, on
> the actual entry point to your program.

In Linux, the arguments are real at the OS level in that they are
individual strings, and are passed from the parent process that way.

In Windows, there is only single command argument string.

Language implementations which support command arguments must provide
the run-time code to parse them out from a single string.

There is more than one way to do that, which can lead to
misunderstandings between programs.

Microsoft describes an algorithm in MSDN. That algorithm is the one used
for the main() function in Microsoft Visual C programs (that are built
with a main; i.e. console applications).

It behooves implementors of command line parsing (or synthesis!) on
Windows to follow that same algorithm/encoding.

There is no hard rule which means that having a main function implies
console application, whereas winMain is a GUI application.

There is a bit in the program header which indicates whether a console
window is created for a program. That's the important thing.

It can be toggled after a program is built.

My TXR langauge for Windows installs two executables: txr.exe and
txr-win.exe. They are the same and both internally have a main(int,
char **). The second one doesn't have a console window come up.
With either of them you can call Win32 APIs to create windows,
with a WndProc callback function to handle events and all that.

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

On 2023-09-08, candycanearter07 <no@thanks.net> wrote:
> The magic of standards is that you don't need to worry about the
> underlying os messiness. With that said, I didn't know about the
> arguments issue, that's neat.

Congratulation on your correct attribution and quoting via T-bird.

That's pretty much a Usenet first. In my memory, nobody who has ever
been told about things like this in any newsgroup I've ever read has
ever done anything to alter their behavior or software configuration.

From QWK packet processing to T-bird is a bit of a jump there.

You would probably rather enjoy text-mode clients like strn, tin,
slrn, ... maybe Emacs' Gnus?

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