Bart <bc@freeuk.com> writes:

> On 04/09/2023 17:16, Ben Bacarisse wrote:
>
>> Do you know that gcc (with no other flags or options) will report no
>> syntax errors for this source code:
>> PROGRAM HELLO
>> WRITE (*,*) 'Hello world'
>> END
>> ? Is it only in "my world" that the plain gcc command is not a C
>> compiler?
>
> Your comments are misleading:

But none the less accurate. Annoying, isn't it? Shall we make a pact
and both agree to make only clear and not at all misleading comments?
You first.

--
Ben.

Bart <bc@freeuk.com> writes:

> On 04/09/2023 20:48, Ben Bacarisse wrote:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>> For a long while I went along with the idea that "C" can mean many
>>>> things, but that's not how Bart uses the term. In fact, that's one of
>>>> his big whinging topics -- C is what you care to make it. So I changed
>>>> my usage and posted the remark above. He found it worthy of mockery,
>>>> but did not want me to respond. Go figure.
>>>
>>> C is a language family, like Lisp. Some people mean "Clojure"
>>> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".
>> Yes.
>
> Examples of versions of the C family which have their own identities?

Do you mean things like ISO/IEC 9899:2017? In general, people tend to
make up their own informal names for the close members of the family.
If you want to know what gcc calls them look at the -std=xxx options.

> I think it's clear we're not talking about distinct languages like
> Objective-C or C++.

In fact, I was talking about languages like Fortran and Go when I said
gcc was not a C compiler.

--
Ben.

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

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 04/09/2023 12:06, Bart wrote:
>
> [...]
>
>>> char* fred(void) {
>>> (long long int)rand()*3.14159;
>>> }
>>> int main(void) {
>>> printf("%s\n", fred());
>>> }
>
> [...]
>
>> As you know, it is not valid C code. As you know, proper C compilers
>> will - at least - warn you about it when asked to treat the input
>> according to the C standards. As you know, there isn't a compiler in
>> the world for any language which will stop programmers from writing
>> incorrect code.
>
> Given the context of the discussion, pedantry seems appropriate.
>
> It's invalid C code because it doesn't declare rand() and printf(),
> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
> (It also contains NO-BREAK SPACE characters, but that's that's just a
> Usenet formatting issue.)
>
> Other than that, a conforming C compiler is not required to diagnose
> the above code. It does have undefined behavior, and a C compiler is
> likely to warn about it with appropriate warnings, but it does not
> violate any syntax rule or constraint.

I say it does.

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:

<snip>

I've posted enough examples over the years for you to have a good idea
of what my language looks like and how it is used. Example:

c:\cx>ms cc -run hello
Compiling hello.c to hello.exe
Hello, World!

This builds my C compiler from source, runs it in-memory and uses it to
compile hello.c and then run that executable.

Learn something about creating lean, genuinely simple, effortless build
systems.

> As I said. It's trivial since the C program has no defined meaning.
>
>>> I post this only to explain how I interpret the notion of "expressing" a
>>> program in another language. I am sure your view of the term is quite
>>> different.
>>
>> 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?

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?

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

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? Even the compilation reported that
it ran into the end of a non-void function.

I'm struggling to reconcile this behaviour, with your statement that 'C
does not allow any such thing'.

Well SOMETHING is allowing it! But you're going to argue that:

* That code was not C
* That had undefined behaviour
* That was not 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.

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

Nobody's mind is going to be changed here.

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. If foo() couldn't sensibly return a value, then
it would default to int, and 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. Compilers will still accept functions which return
garbage values. Presumably for backwards compatibility, 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.

On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in
<ucvuhq$gmlg$1@dont-email.me>:

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

Isn't asking a C compiler to watch for interminable loops and
such things akin to trying to solve the halting problem?

I mean, I'm not the smartest person in the room by far, but even
I know that this is, perhaps, a bit far-out...

...or is it? I could be mistaken.

--
-v

On 8/10/2023 4:57 AM, Bart wrote:
> On 10/08/2023 12:29, Paul Edwards wrote:
> > Hi Bart.
[...]

Creating a compiler reminds of the following song:

https://youtu.be/_jEP347F6_g

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 04/09/2023 12:06, Bart wrote:
>> [...]
>>
>>>> char* fred(void) {
>>>> (long long int)rand()*3.14159;
>>>> }
>>>> int main(void) {
>>>> printf("%s\n", fred());
>>>> }
>>
>> [...]
>>
>>> As you know, it is not valid C code. As you know, proper C compilers
>>> will - at least - warn you about it when asked to treat the input
>>> according to the C standards. As you know, there isn't a compiler in
>>> the world for any language which will stop programmers from writing
>>> incorrect code.
>>
>> Given the context of the discussion, pedantry seems appropriate.
>>
>> It's invalid C code because it doesn't declare rand() and printf(),
>> correctable by adding `#include <stdlib.h>` and `#include <stdio.h>`.
>> (It also contains NO-BREAK SPACE characters, but that's that's just a
>> Usenet formatting issue.)
>>
>> Other than that, a conforming C compiler is not required to diagnose
>> the above code. It does have undefined behavior, and a C compiler is
>> likely to warn about it with appropriate warnings, but it does not
>> violate any syntax rule or constraint.
>
> I say it does.

If you're right, then gcc 13.2.0 and clang 16.0.0 have a bug. Both
compile the above code (once the required #include directives are added)
without error, though clang prints a couple of optional warnings. I used
"-std=c17 -pedantic-errors" with both compilers. (With "-Wall", gcc
prints warnings similar to the ones clang prints without it.)

What syntax rule or constraint does it violate?

Does it occur to you that you would save everyone a lot of time if
you'd explain what you mean in the first place?

--
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/4/23 6:38 PM, vallor wrote:
> On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in
> <ucvuhq$gmlg$1@dont-email.me>:
>
>> If you have a function that you know will never return (becauses it
>> stays in a loop, or terminates, here or in a nested function), then why
>> would you give it a return type in the first place?
>
> Isn't asking a C compiler to watch for interminable loops and
> such things akin to trying to solve the halting problem?
>
> I mean, I'm not the smartest person in the room by far, but even
> I know that this is, perhaps, a bit far-out...
>
> ...or is it? I could be mistaken.
>

I think the proposal to have it look to see if something might happen
was limited to evaluating CONSTANT values.

I seem to remember that a loop with a non-constant-expression control
expression allowed the complier to assume the loop will eventually end,
and thus if the loop had no observable effects, could be optimized away,
even if it turns out that the condition could never be met.

Thus, it doesn't become a Halting Problem analysis, as loop termination
becomes "correctly" predicted syntactic means.

On 2023-09-05, vallor <vallor@cultnix.org> wrote:
> On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in
><ucvuhq$gmlg$1@dont-email.me>:
>
>> If you have a function that you know will never return (becauses it
>> stays in a loop, or terminates, here or in a nested function), then why
>> would you give it a return type in the first place?
>
> Isn't asking a C compiler to watch for interminable loops and
> such things akin to trying to solve the halting problem?

The Halting Problem is academic. The main reasons why you can't
accurately determine reachability in C programs are practical:

- the compiler doesn't have the entire program, only a translation unit.
Whenever the reachability calculation depends on the result of an
external function, or value of an external variable or other object
whose manipulation is not entirely visible in the current translation
unit, a prudent assumption has to be made.

- there are also run-time inputs.

A Turing machine is completely defined and has no run-time inputs;
everything is on the tape.

A C program that is all in one translation unit, and takes no
input from the environment, resembles a Turing Machine.

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

On 04/09/2023 22:06, Bart wrote:
> On 04/09/2023 20:17, Kaz Kylheku wrote:
>> On 2023-09-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> For a long while I went along with the idea that "C" can mean many
>>> things, but that's not how Bart uses the term.  In fact, that's one of
>>> his big whinging topics -- C is what you care to make it.  So I changed
>>> my usage and posted the remark above.  He found it worthy of mockery,
>>> but did not want me to respond.  Go figure.
>>
>> C is a language family, like Lisp. Some people mean "Clojure"
>> when they are sayhing Lisp, some mean "Racket" or "Emacs Lisp".
>
> But there is still one current C standard, and one current set of
> standard headers?

There is one single official current C standard - currently C17. There
are older published C standards, which are still very relevant despite
being superseded by the latest version.

The standards documents from ISO cost money to buy, but drafts are
freely available - the final draft before publishing is typically
identical baring insignificant typographic fixes.

There is not a single set of standard headers. The requirements for the
standard library headers (and standard library functions) are part of
the C standards, but the headers themselves are provided by each C
implementation. It is common, but not required, for C compilers to have
the headers that don't have function declarations (such as <stdint.h>)
and are used for freestanding and hosted implementations, while other
headers are part of a standard library.

But different implementations will have different sets of standard
library headers as well as different implementations of the standard
library functions. And of course OS-specific headers are not part of
the C standard at all (even if they happen to be bundled along with a
compiler in some cases).

>
>>
>> Bart will just have to be patiently educated in the differences among:
>>
>> - language family
>> - language dialect
>> - language standard
>> - language implementation
>> - language reference manual
>
>
> Sure, how much more complicated do you want to make it?
>
> But while you're here, perhaps you can tell me which of those myriad Cs
> is being compiled in each case here:
>
>   gcc prog.c
>   clang prog.c
>   tcc lang.c
>   msvc lang.c
>   zig cc lang.c
>   lcc lang.c
>   pellesc lang.c       (I forget the actual compiler name)
>
> None of those likes to be verbose so it's rather a mystery what exactly
> they are doing.

It's not really a mystery in at least some of the cases. gcc and clang
have quite comprehensive documentation - you can easily look up the
options for the standards supported, as well as the default standard
(for the particular version of the compiler). I am not as familiar with
msvc, but I understand it too has a lot of documentation available.

As for the rest, I have not checked - and have no intention of doing so.
Some compilers provide good documentation, others do not. If you want
to use a particular tool, it makes sense to learn what it does - and if
you can't find out, it may not be a good choice of tool.

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

Read the documentation. Since a C compiler should not be giving a hard
error for the missing return, all we know is that compilers that /do/
give a hard error are not implementing standard C. But for details, see
the documentation.

>
> Do I have to to specify -Werror=xxx 173 times for all the possible
> things that ought to sensibly be hard errors?

"Sensible" in whose eyes? Yours? Silly question - of course that's
what you meant, because you are the sole judge of what is "sensible".

>
> BTW apparently 'gcc' is not a C compiler.

"gcc" is the "GNU Compiler Collection". It certainly /can/ be a C
compiler - but it is also many other things. Without additional flags,
it will compile an extended C dialect that has additional features
beyond the standard, and is also laxer (especially about supporting
newer or older constructs). This is all documented, and nothing new to you.

With appropriate flags (they are not particularly difficult) it will
support your choice of C standard. Additional flags can be used to
restrict the accepted code to a subset of this with warnings or error
messages for going outside that subset - such as requiring the use of
"return value;" statements in non-void functions.

"gcc" is also, depending on the details of the configuration, a Fortran
compiler, a D compiler, and a compiler for several other languages, as
well as a driver program and front-end for an assembler and a linker.

> That's both an interesting and
> useless bit of information. What is means is that 'gcc.exe' invokes
> programs like 'cc.exe', 'as.exe' and 'ld.exe', when presented with a -xc
> option or a .c file extension, but people, in a C context, colloquially
> refer to 'gcc' as a C compiler.
>

People do indeed refer to it colloquially as a C compiler - and
colloquially, that's absolutely fine. But if you want to be precise
about the exact handling of corners of the language, "colloquial" will
not do - you choose to go down that path, so you need to learn about
what "C" means technically, not just colloquially.

>
> I think you guys just want to keep things a mystery!

How can you possibly think that? People have explained this stuff to
you hundreds of times over a decade or more. For at least the serious
tools, all the information is clearly given in reference manuals online.
And if that were not enough, ten seconds of googling should give you
everything you are asking.

The only reason any of this is a mystery to you is the extraordinary
effort you put in to resist any attempt at understanding or learning.

On 05/09/2023 02:38, vallor wrote:
> On Sat, 2 Sep 2023 19:22:50 +0100, Bart <bc@freeuk.com> wrote in
> <ucvuhq$gmlg$1@dont-email.me>:
>
>> If you have a function that you know will never return (becauses it
>> stays in a loop, or terminates, here or in a nested function), then why
>> would you give it a return type in the first place?
>
> Isn't asking a C compiler to watch for interminable loops and
> such things akin to trying to solve the halting problem?

Read my question again: if the programmer /knows/ it will never return.

Then they can choose to use a void function. (In the example given,
there was a need to match a non-void function.)

If you mean, whether a compiler can tell for sure whether it will reach
the end or not, then you're right, it can't:

int F(void) {
if (rand()!=12345) return 100;
}

I made a decision to require a return statement as the last or within a
branch of the last statement. That means this program fails as written.

That can be overridden because such programs exist in the wild. In this
case, what I can do (but haven't done and others don't do that I can
see), is to zero the register where a return value is expected, to give
at least predictable and repeatable behaviour.

You might say, that's an extra few bytes that might not be needed. But
compilers do seem to generate function epilogue code in this situation;
what's the point of that when the compiler assumes it cannot run into
the end because it would be UB?

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. It would be pointless to talk about "Turing machines"
if all a given "Turing machine" could do is one computation.

> A C program that is all in one translation unit, and takes no
> input from the environment, resembles a Turing Machine.

A Turing machine is analogous to a program, with the tape being
analogous to program input.

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.

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.

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

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.

You can download and read the document to alleviate your ignorance.

https://methamphetaminebox.com/
https://methamphetaminebox.com/product/buy-dmt-5ml-deadhead-chemist-cartridge/
https://methamphetaminebox.com/product/buy-schwifty-labs-1ml-dmt-cartridge/
https://methamphetaminebox.com/product/buy-schwifty-labs-1ml-5-meo-dmt-cartridge/
https://methamphetaminebox.com/product/buy-schwifty-labs-5ml-dmt-cartridge/
https://methamphetaminebox.com/product/buy-schwifty-labs-5-ml-5-meo-dmt-cartridge/
https://methamphetaminebox.com/product/buy-purecybin-1ml-700mg-dmt-carts/
https://methamphetaminebox.com/product/buy-puff-boyz-nn-dmt-5ml400mg-wild-apple-carts/
https://methamphetaminebox.com/product/buy-puff-boyz-nn-dmt-5ml400mg-wild-apple-carts/
https://methamphetaminebox.com/product/buy-crystal-meth-online/
https://methamphetaminebox.com/product/buy-4-fa-powder-online/
https://methamphetaminebox.com/product/buy-25i-nbome-powder-legally/
https://methamphetaminebox.com/product/a-pvp-crystals-for-sale/
https://methamphetaminebox.com/product/buy-alprazolam-powder-updated-2023/
https://methamphetaminebox.com/product/buy-alprazolam-powder-updated-2023/
https://methamphetaminebox.com/product/buy-dmt-crystal-online/
https://methamphetaminebox.com/product/buy-diclazepam-online/

On 05/09/2023 16:33, Bart wrote:
> 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.

Is there some reason that you won't look at the standard here? There
are parts of the C standards that are a bit difficult to read, but
surely you are able to read enough to determine the answer for yourself?
Certainly /I/ would be happier to hear that you have looked at the
standards document yourself and understood it. No one wants you just to
take their word for it - after all, you believe very little of things
other people write, and twist much of it to fit your paranoia and confusion.

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

On 05/09/2023 16:31, David Brown wrote

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

>  There
> are parts of the C standards that are a bit difficult to read, but
> surely you are able to read enough to determine the answer for yourself?
>  Certainly /I/ would be happier to hear that you have looked at the
> standards document yourself and understood it.

The standard wouldn't be enough. I'd need to know the reasons behind why
it says what it says.

If it is more lax than I would like, is that because it it had to
reflect widespread disregard in the existing range of compilers, rather
than what would be a preferable and safer guidance?

And if it is more strict about something I don't consider important, how
seriously should I have to take it?

Because I don't believe in warnings on a routine compilation, I need to
consider carefully whether something should be failed. I like to base
that also on the extensive experience I have with my own languages.

We need to end up with practical, useful tools.

Take this bit of code:

int* p;
double* q;

p = q;

These pointers are not compatible. Now for many years, my own language
ignored that fact, after all these are just addresses. Until I spent 6
hours tracking down a bug caused by such a mismatch.

Now it is a hard error in my language, and in my C compiler.

Not in most compilers however. Should I need to look at the C standard
for guidance? Honestly, I don't care what it says about it. That's the
same document that tells me I can't use an EXPLICIT CAST to convert an
address from a function type to object type or some thing (but two
nested casts are fine!).

Presumably, since compilers don't normally fail this, it's not going to
care what they do. Either it's going say a diagnostic is not required,
or one is, but it's not going to say it needs to be a fatal one (what
/should/ be fatal according to the C standard?).

So common sense plays a bigger role here. In my compiler you have to do
one of:

p = (int*)q;
p = (void*)q;

At least it will until forced to relax that because there is so much bad
code about due to decades of lax compilers.

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

I picked up the synecdoche somewhere.

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

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

On 2023-09-05, Bart <bc@freeuk.com> wrote:
> The standard wouldn't be enough. I'd need to know the reasons behind why
> it says what it says.

When the first C standard was ratified in 1989, the committee wrote a
Rationale. If you google for "ANSI C Rationale" you can find it.

There are footnotes in every revision in the standard which sometimes
give clarifications that constitute rationalee.

> If it is more lax than I would like, is that because it it had to
> reflect widespread disregard in the existing range of compilers, rather
> than what would be a preferable and safer guidance?
>
> And if it is more strict about something I don't consider important, how
> seriously should I have to take it?

In that case, you can emulate the thinking of Richard Stallman and GNU.

In the GNU Coding Standards, there are passages about external
sstandards: https://www.gnu.org/prep/standards/

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

[ ... snip ... ]

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

I don't agree with everything in the second paragraph, but it gives
you a flavor for why GCC is the way it is, and why it accepts the
GNU C dialect by default, in which syntax that is invalid ISO C
has a meaning and is accepted silently.

When they say there is no reason to use --pedantic, they are saying
there is no reason to use any compiler other than GCC, and therefore
no reason to diagnose whether your code has nonportable GCC-only
features.

> Because I don't believe in warnings on a routine compilation, I need to
> consider carefully whether something should be failed. I like to base
> that also on the extensive experience I have with my own languages.
>
> We need to end up with practical, useful tools.
>
> Take this bit of code:
>
> int* p;
> double* q;
>
> p = q;
>
> These pointers are not compatible. Now for many years, my own language
> ignored that fact, after all these are just addresses. Until I spent 6
> hours tracking down a bug caused by such a mismatch.

Right? So at least a warning diagnostic is useful. The ISO C standard
doesn't distinguis warning and error diagnostics. It specifies only
diagnostics. If a program requires an diagnostic by ISO C, the
implementation may also stop translating it. If it is translated anyway,
it has undefined behavior.

GCC warns about a conversion between unlike pointers without a cast;
if a cast is used, then there is no diagnostic.

> Now it is a hard error in my language, and in my C compiler.

Like with gcc -Werror=incompatible-pointer-types.

To the astute developer compiling programs locally, there is
no difference; that developer takes warnings seriously.

In large team projects, you can get sloppy programmers who don't
pay attention to warnings. Code is submitted to some review system which
builds the code. Reviewers typically don't look at the build log, only
at the code and the fact that the build passed. (Code built, unit tests
went "green"). So it's easy for warnings to go unnoticed.

> Not in most compilers however. Should I need to look at the C standard
> for guidance? Honestly, I don't care what it says about it.

The right attitude is to care about the bug first. But what the
standard says about it is important for conformance.

> That's the
> same document that tells me I can't use an EXPLICIT CAST to convert an
> address from a function type to object type or some thing (but two
> nested casts are fine!).

This is explicitly acknowledged as a common extension in an Appendix!

It is not disallowed; no diagnostic is required for a program which
performs that conversion with a cast. It is undefined behavior.

If your compiler cannot support a certain conversion (like say that
for some reason you had had 128 bit function pointers, but 64 bit data
pointers), then it would make sense for it to diagnose that the
conversion can't be done.

> Presumably, since compilers don't normally fail this, it's not going to
> care what they do. Either it's going say a diagnostic is not required,
> or one is, but it's not going to say it needs to be a fatal one (what
> /should/ be fatal according to the C standard?).

Nothing is ever required to be fatal! Some things must be diagnosed,
but diagnostics are not required to be fatal.

Diagnostics that are required are not required to be distinguishable
from custom diagnostics developed by the implementation.

> So common sense plays a bigger role here. In my compiler you have to do
> one of:
>
> p = (int*)q;
> p = (void*)q;
>
> At least it will until forced to relax that because there is so much bad
> code about due to decades of lax compilers.

Yes, other lax compilers can create pressure for yours to be lax.

If someone has a big program with a 1000 instances of a pointer
conversion without a cast, which someone else's compiler only warns
about, and your compiler bails on the first instance, that goofy user
might sadly choose to avoid your compiler than fix their code.

In general, many people working with C are not familiar with the
standard.

Then there are those that are, and abhor the idea that a program
compiles if it converts between pointers without a cast.

You can see why GCC is flexible about picking and choosing diagnostics,
and whether they are fatal.

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

On 05/09/2023 19:06, Bart wrote:
> On 05/09/2023 16:31, David Brown wrote
>
> BC:
>>> 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.
>>
>> 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.
>

I regularly give you references in the C standard, so that you don't
need to figure out where to look. But do you ever use these references?

Have you ever looked at the C standards (any version) ? For that
matter, have you ever looked at a Bible - clearly you've skipped at
least one of these.

Read "6.8.6.4 The return statement" and "6.9.1 Function definitions".
No more pathetic excuses.

>
>>   There are parts of the C standards that are a bit difficult to read,
>> but surely you are able to read enough to determine the answer for
>> yourself?   Certainly /I/ would be happier to hear that you have
>> looked at the standards document yourself and understood it.
>
> The standard wouldn't be enough. I'd need to know the reasons behind why
> it says what it says.

Start with the standard, and let's go from there. Learn what it says,
then ask why, then listen when people tell you.

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.

On 05/09/2023 19:10, David Brown wrote:
> On 05/09/2023 19:06, Bart wrote:
>> On 05/09/2023 16:31, David Brown wrote
>>
>> BC:
>>>> 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.
>>>
>>> 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.
>>
>
> I regularly give you references in the C standard, so that you don't
> need to figure out where to look.  But do you ever use these references?
>
> Have you ever looked at the C standards (any version) ?  For that
> matter, have you ever looked at a Bible - clearly you've skipped at
> least one of these.

Admired it, yes. I have a huge edition printed in 1792.

>
> Read "6.8.6.4 The return statement"

6.8.6.4p1 says:

"1 A return statement with an expression shall not appear in a function
whose return type is void. A return statement without an expression
shall only appear in a function whose return type is void."

Aren't these the exact same examples that I recently posted? I already
said I fail those. Although looking at that wording, it is quite
confusing. It appears to say this:

Void func Non-void func

return expr; Not allowed (1)

return; Only here (2)

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.

I guess some other sections explains how those are handled.

> and "6.9.1 Function definitions". No
> more pathetic excuses.
>
>
>>
>>>   There are parts of the C standards that are a bit difficult to
>>> read, but surely you are able to read enough to determine the answer
>>> for yourself?   Certainly /I/ would be happier to hear that you have
>>> looked at the standards document yourself and understood it.
>>
>> The standard wouldn't be enough. I'd need to know the reasons behind
>> why it says what it says.
>
> Start with the standard, and let's go from there.  Learn what it says,
> then ask why, then listen when people tell you.

You sound like a Jehovah's Witness.

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

It would help if you weren't so bloody patronising.

On 05/09/2023 21:57, Bart wrote:
> On 05/09/2023 19:10, David Brown wrote:
>> On 05/09/2023 19:06, Bart wrote:
>>> On 05/09/2023 16:31, David Brown wrote
>>>
>>> BC:
>>>>> 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.
>>>>
>>>> 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.
>>>
>>
>> I regularly give you references in the C standard, so that you don't
>> need to figure out where to look.  But do you ever use these references?
>>
>> Have you ever looked at the C standards (any version) ?  For that
>> matter, have you ever looked at a Bible - clearly you've skipped at
>> least one of these.
>
> Admired it, yes. I have a huge edition printed in 1792.
>
>>
>> Read "6.8.6.4 The return statement"
>
> 6.8.6.4p1 says:
>
> "1 A return statement with an expression shall not appear in a function
> whose return type is void. A return statement without an expression
> shall only appear in a function whose return type is void."
>
> Aren't these the exact same examples that I recently posted? I already
> said I fail those. Although looking at that wording, it is quite
> confusing. It appears to say this:
>
>                    Void func     Non-void func
>
>   return expr;     Not allowed   (1)
>
>   return;          Only here     (2)
>
> 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.

>
>> and "6.9.1 Function definitions". No more pathetic excuses.

See 6.9.1p12 :

"Unless otherwise specified, if the } that terminates a function is
reached, and the value of the function call is used by the caller, the
behaviour is undefined."

Running off the end of a non-void function is only a problem if the the
caller tries to use the value. Otherwise it is fine. Bad coding
practice, perhaps, and worthy of a warning message in my opinion, but it
is valid C code and a C compiler needs to accept it (optionally with a
warning message) and not reject it.

>>
>>
>>>
>>>>   There are parts of the C standards that are a bit difficult to
>>>> read, but surely you are able to read enough to determine the answer
>>>> for yourself?   Certainly /I/ would be happier to hear that you have
>>>> looked at the standards document yourself and understood it.
>>>
>>> The standard wouldn't be enough. I'd need to know the reasons behind
>>> why it says what it says.
>>
>> Start with the standard, and let's go from there.  Learn what it says,
>> then ask why, then listen when people tell you.
>
> You sound like a Jehovah's Witness.

The difference is, the C standard is real.

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. It will make it much easier to write a C
implementation.

>
> It would help if you weren't so bloody patronising.

If you think I am patronising, it is because you act like a small child.
Grow up, stop whining, drop the paranoia, ask sensible questions, pay
attention to the answers, and answer the questions you are given. It
will make things a lot easier, and you'll learn much more.

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

"X shall appear only in Y" means "in Y and nowhere else". If it appears
anywhere but Y, the "shall" requirement is violated.

If that is in a "Constraints" paragraph, it requires a diagnotic.

Just like "parking is allowed only in designated stalls" means not
in the driveway, or on the lawn, or elsewhere.

--
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-05, Bart <bc@freeuk.com> wrote:
> This paragraph calls them Constraints, as presumably they can't be
> expressed via syntax.

Contraints paragraphs give rules that require diagnostics if they
are violated, which is in the same class a syntax errors.

Some constraints could be turned into syntax.

For instance, the combinations of type specifiers could all be phrase
structures which admit "unsigned int" but not "unsigned struct foo".

How ISO specifies it is that any jumble of type specifiers is allowed,
and then constraints rules allow only certain combinations.

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