On 01/09/2023 19:07, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 01/09/2023 13:08, Richard Harnden wrote:
>>>>> On 01/09/2023 12:01, Bart wrote:
>>>
>>>>>> We are talking about compilers like gcc where you make up your own rules
>>>>>> as to show strictly you want your program treated:
>>>>>>
>>>>>>   gcc prog.c              zero warnings, writes .exe
>>>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>>
>>> Which would you choose as the one and only behaviour?
>
> No answer? I'll look at the rest of your post, if you decide to address
> this point...

I'm not the compiler. It's supposed to tell me if my program passes.

There are apparently millions of possibilities, from zero errors to
1000s, for example if you apply -Werror.

Yes, it would be great if exam papers worked like that, you can choose
how strictly they should be marked!

But it's somewhat worrying here.

You want an answer, I'd go with the first, since then the three
compilers I use the most work the same way.

That's not completely satisfactory, since there are aspects of the C
language I think are too unsafe, but:

* Have to be passed because they are legal C

* Cannot reliably be detected by a compiler

* Are too extensively used in legacy code to be just outlawed.

In mine, I deal with the last by having a legacy option (called -old)
that needs to be invoked for existing programs. But unlike ones like
gcc, that is not the default; the option must be specified.

So my product works with two dialects, old and new.

But its behaviour, given one of those, is unequivocal:

bcc prog zero errors, writes .exe

or:

bcc prog exactly one error (as it stops compilation),
no .exe produced

Given that I have a short memory, and can only fix one error at a time,
that is reasonable.

Also time to restart compilation is not an issue; it's not as though it
is an overnight build using punched cards and you have to find as many
things wrong as possible during each attempt.

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 14:53, Ben Bacarisse wrote:
>> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not
>> overruled by command line warning options, but there may be a way to
>> force these to be ignored.
>
> Those don't always work. At least this doesn't:
>
> #pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
>
> It works on Windows gcc but not WSL gcc.

"WSL gcc" is not the designation of a version of GCC.

Not all versions of GCC have the same -W options because, doh,
new ones get added over time.

Unfortunately, when you give a new -W option to an old GCC,
it has a fit about an unrecognized option and bails.

Projects that want to take advantage of new options, but still
work with olde GCC's, have a slight problem.

One approach is to detect what options work, in your ./configure script.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> Is my program correct? Apparently gcc can't tell me; *I* have to tell
> *it*. You pretty much say that above.

GCC can't tell you whether a program is correct, because it can't read
your requirement specification, high level design or detailed design.
It doesn't run your program, let alone execute test cases on it.

> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
> messages, then my program is fine.

Even if ./a.out segfaults? Yes, if the requirement specification
for the program is "write me small program that segfaults on Unix".
It would then be incorrect if it terminated normally.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> If I compile my generated C with any of:
>
> bcc prog
> tcc prog.c
> gcc prog.c -oprog
>
> it works perfectly.
>
> Unless there's actually something wrong with prog.c. In that case:
>
> * Why doesn't gcc show any errors?

Because, in general, determining that "something is wrong" with a
program is equivalent in difficulty to the Halting Problem, **and**
being able to tell that something is wrong requires understanding the
requirements specification for the program.

> * Why not even warnings?

You've not specified -W, and the program doesn't violate any
syntax rulews or constraint rules of GNU C (the default dialect).

> * Why is it generating an executable?

That compiler have you written that emits diagnostics and fails to
generate an executable whenever "something is wrong" with the program,
and how did you do it?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 19:07, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 01/09/2023 13:08, Richard Harnden wrote:
>>>>>> On 01/09/2023 12:01, Bart wrote:
>>>>
>>>>>>> We are talking about compilers like gcc where you make up your own rules
>>>>>>> as to show strictly you want your program treated:
>>>>>>>
>>>>>>>   gcc prog.c              zero warnings, writes .exe
>>>>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>>>
>>>> Which would you choose as the one and only behaviour?
>>
>> No answer? I'll look at the rest of your post, if you decide to address
>> this point...
>
> I'm not the compiler. It's supposed to tell me if my program passes.

Passes what? The regression test suite?

Is that what your own compilers do; build the program and run a
test suite?

Do they propose and generate the test suite, or does the hapless
programmer actually have to provide one?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>>> Is that true? #pragma GCC diagnostic "-Wno-xxxx" lines are not
>>> overruled by command line warning options, but there may be a way to
>>> force these to be ignored.
>>
>> Those don't always work. At least this doesn't:
>>
>> #pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
>>
>> It works on Windows gcc but not WSL gcc.
>
>"WSL gcc" is not the designation of a version of GCC.
>
>Not all versions of GCC have the same -W options because, doh,
>new ones get added over time.
>
>Unfortunately, when you give a new -W option to an old GCC,
>it has a fit about an unrecognized option and bails.
>
>Projects that want to take advantage of new options, but still
>work with olde GCC's, have a slight problem.
>
>One approach is to detect what options work, in your ./configure script.

Or in the Makefile if you don't use autoconf.

GCC_HAS_GENERIC_TUNING := $(shell expr `$(CXX) -dumpversion | cut -f2 -d. ` \>= 2)
GCC_HAS_MCRC32 := $(shell expr `$(CXX) -E -mcrc32 /dev/null 2>/dev/null; echo $$?` == 0)

IS_GCC_MAJOR_VER_4 := $(shell if [ `$(CXX) -dumpversion | cut -f1 -d. ` -eq 4 ]; then echo 1; else echo 0; fi )

On 01/09/2023 19:55, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> On 01/09/2023 19:07, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 01/09/2023 13:08, Richard Harnden wrote:
>>>>>>> On 01/09/2023 12:01, Bart wrote:
>>>>>
>>>>>>>> We are talking about compilers like gcc where you make up your own rules
>>>>>>>> as to show strictly you want your program treated:
>>>>>>>>
>>>>>>>>   gcc prog.c              zero warnings, writes .exe
>>>>>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>>>>
>>>>> Which would you choose as the one and only behaviour?
>>>
>>> No answer? I'll look at the rest of your post, if you decide to address
>>> this point...
>>
>> I'm not the compiler. It's supposed to tell me if my program passes.
>
> Passes what? The regression test suite?
>
> Is that what your own compilers do; build the program and run a
> test suite?

So, what the hell does gcc actually do? gcc or any of its ilk since all
seem to want to emulate it.

I'm genuinely interested.

It seems incredibly laid-back about the whole business. Sometimes a
program is OK, sometimes it isn't, sometimes it fails, depending on how
how much of a bribe - sorry, a set of options - that you give it.

MY compilers check that an input sourcefile for language L has a valid
syntax, can fully resolve name references, obeys the type rules of the
language, and does various other bits and pieces.

If anything fails, it stops. If that's all OK according to the language
rules, it will produce an executable.

It doesn't do any speculative analysis. It can't tell whether logic or
design bugs exist or not. It doesn't get involved in what you do with
the executable, or what tests you might choose to perform.

It just does what is expected of a COMPILER - a tool to turn source code
into runnable binary code as instructed by program statements within
that source code.

So how does gcc manage to do pretty much what it likes, including either
compiling a program with no errors or warnings, or compiling the SAME
PROGRAM with fatal errors?

On 01/09/2023 19:49, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> Is my program correct? Apparently gcc can't tell me; *I* have to tell
>> *it*. You pretty much say that above.
>
> GCC can't tell you whether a program is correct, because it can't read
> your requirement specification, high level design or detailed design.
> It doesn't run your program, let alone execute test cases on it.
>
>> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
>> messages, then my program is fine.
>
> Even if ./a.out segfaults? Yes, if the requirement specification
> for the program is "write me small program that segfaults on Unix".
> It would then be incorrect if it terminated normally.
>

Ok, since you seem determined to misunderstand.

Is my program a valid C program? The answer seems to depend on a lot
more than just the source code submitted.

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> MY compilers check that an input sourcefile for language L has a valid
> syntax,

Which valid syntax? As of the last night's commit which added new
syntax?

What if I have code that uses last year's syntax, and for the
time being want to keep it that way (not have newer syntax
creeping in accidentally?)

Oh shit! Look, someone likes your language and has written their
own implementation. It has a few differences and extensions.
Users are starting to use them and complaining they don't work
in the original.

Do you support those, unconditionally?

> can fully resolve name references, obeys the type rules of the
> language, and does various other bits and pieces.

Do your compilers target PPC? I have a project that runs on big endian
PPC64. Also ported it to Loongarch: this new ISA from China.

SPARC? MIPS? RISCV?

Oh wait yes; thanks to GCC ...

> So how does gcc manage to do pretty much what it likes, including either
> compiling a program with no errors or warnings, or compiling the SAME
> PROGRAM with fatal errors?

By supporting forty years of C revisions, plus its dialect, plus having
flexible code generation and diagnosis options, that the users want and
depend on.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 19:49, Kaz Kylheku wrote:
>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>> Is my program correct? Apparently gcc can't tell me; *I* have to tell
>>> *it*. You pretty much say that above.
>>
>> GCC can't tell you whether a program is correct, because it can't read
>> your requirement specification, high level design or detailed design.
>> It doesn't run your program, let alone execute test cases on it.
>>
>>> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
>>> messages, then my program is fine.
>>
>> Even if ./a.out segfaults? Yes, if the requirement specification
>> for the program is "write me small program that segfaults on Unix".
>> It would then be incorrect if it terminated normally.
>>
>
> Ok, since you seem determined to misunderstand.

It's you who don't understand what "correct" means.

When you start talking about correctness, the program's specification
is involved.

In fact that is all that is involved. A null pointer dereference
or division by zero become correct if the specification says so.

> Is my program a valid C program? The answer seems to depend on a lot
> more than just the source code submitted.

C is a family of languages with many dialects. An almost fifty-year-old
family. C++ is a C dialect. Objective C is a C dialect.

What does your question mean?

Does your question mean "is this program a valid program in absolutely
any C dialect that has ever existed, such that all its externally
visible behaviors are the same?"

That's not easy to answer, or practically useful; maybe you
mean something else?

gcc is a program that processes code in the C family and other families.
It has dialect options, as well as customization that allow users
create custom dialects, within certain obvious limits.

A configuration of gcc processes one dialect, so it can tell you whether
the program is acceptable under that dialect.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 01/09/2023 21:46, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> MY compilers check that an input sourcefile for language L has a valid
>> syntax,
>
> Which valid syntax? As of the last night's commit which added new
> syntax?
>
> What if I have code that uses last year's syntax, and for the
> time being want to keep it that way (not have newer syntax
> creeping in accidentally?)
>
> Oh shit! Look, someone likes your language and has written their
> own implementation. It has a few differences and extensions.
> Users are starting to use them and complaining they don't work
> in the original.
>
> Do you support those, unconditionally?
>
>> can fully resolve name references, obeys the type rules of the
>> language, and does various other bits and pieces.
>
> Do your compilers target PPC? I have a project that runs on big endian
> PPC64. Also ported it to Loongarch: this new ISA from China.
>
> SPARC? MIPS? RISCV?
>
> Oh wait yes; thanks to GCC ...
>
>> So how does gcc manage to do pretty much what it likes, including either
>> compiling a program with no errors or warnings, or compiling the SAME
>> PROGRAM with fatal errors?
>
> By supporting forty years of C revisions, plus its dialect, plus having
> flexible code generation and diagnosis options, that the users want and
> depend on.
>

So you freely admit that C is a mess, and so are its compilers.

And yet, it is possible to create a compiler that gives the common-sense
results that one would expect. Except I'm not seeing it.

What do you expect the results of compiling this program with -c to be:

int fred(void){}

Here are the results I get:

Warnings Errors

gcc - -
tcc - -
clang 1 -
msvc 1 -
gcc -Wall 1 -
lccwin32 1 -
bcc - 1

The problem with that function, in case you haven't spotted it, is that
it does not return an 'int' value.

Yet, not one of those compilers other than bcc stops you creating an
executable containing a call to that function.

That can be serious, especially if the return type was a pointer.

This is just incredible. You can spout all the nonsense you like about
the long history of C, but there is no excuse for a compiler in 2023 to
pass code like that with default behaviour.

You have to give gcc -Wall to even get it to warn.

Yet, everyone here will either defend it to the death, or just brush it
off and say, Of couse, you have to provide the right options to get the
compiler to do its job properly.

(BTW, which option do you need to force a hard error on that program,
which doesn't also fail on unused lables?)

I would say, WHY doesn't it do its job anyway? WHY doesn't it operate in
a safer mode by default?

I can get my bcc to pass that program, but I have to specify -old, and
that is only so that existing can be compiled.

But why do so many existing programs have such code? Could it possibly
be because compilers have always allowed it? So the practice is
perpetuated instead of curtailed.

There is something very, very wrong with the culture of both C, and its
retinue of compilers.

Yes, I want a simple universal language that exists on every platform. I
just wish it was something better than this.

And BTW, WTF does it have to do with being to run on PPC? Does that
machine magically conjure the expected return value out of thin air. Or
are just trying to belittle my own efforts?

No doubt you, DB, KT, and everyone else will insist it is still my
fault. How about admitting that things are not as they should be?

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> On 01/09/2023 09:43, David Brown wrote:
>>> On 31/08/2023 21:26, Bart wrote:
>>
>>> Putting object files in the current directory is a useful default.
>>
>> 'gcc -c' will do that if the input file is in the same current directory.
>>
>> So if the current directory happens to be /abc, compiling hello.c will
>> produce /abc/hello.o from /abc/hello.c.
>
> You are right. I didn't even notice that or forgot about it all these
> years. -c is only used in very trivial makefiles.
>
> The built-in make recipe doesn't use it; it uses -o so that if you say,
>
> obj/foo.o: src/foo.c
>
> it works fine.
> According to the gcc man page, I would think that
> -c turns src/foo.c into src/foo.o.

Yes, and it works by invoking gcc with the "-c" option, which make knows
how to do.

For GNU make, `make -p` dumps the data base of rules and variable
values. On my system, part of the output is:

COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c

Ignoring directory issues, if you want to generate an object file foo.o
from a C source file foo.c, you can use `gcc foo.c -c` or `gcc -c foo.c`
-- or, if you want to be explicit, `gcc foo.c -c -o foo.o`.

If you do `gcc foo.c -o foo.o`, the lack of a `-c` option tells it to
invoke the linker. It will create an executable, not an object file,
named "foo.o". That's very probably not what you want.

> Quote
>
> By default, the object file name for a source file is made by
> replacing the suffix .c, .i, .s, etc., with .o.

I agree that's potentially misleading. I think the intent was that
"object file name" is intended to refer just to the file *name*, not the
full file *path*.

[...]

--
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 01/09/2023 22:09, Kaz Kylheku wrote:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> On 01/09/2023 19:49, Kaz Kylheku wrote:
>>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>>> Is my program correct? Apparently gcc can't tell me; *I* have to tell
>>>> *it*. You pretty much say that above.
>>>
>>> GCC can't tell you whether a program is correct, because it can't read
>>> your requirement specification, high level design or detailed design.
>>> It doesn't run your program, let alone execute test cases on it.
>>>
>>>> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
>>>> messages, then my program is fine.
>>>
>>> Even if ./a.out segfaults? Yes, if the requirement specification
>>> for the program is "write me small program that segfaults on Unix".
>>> It would then be incorrect if it terminated normally.
>>>
>>
>> Ok, since you seem determined to misunderstand.
>
> It's you who don't understand what "correct" means.
>
> When you start talking about correctness, the program's specification
> is involved.
>
> In fact that is all that is involved. A null pointer dereference
> or division by zero become correct if the specification says so.
>
>> Is my program a valid C program? The answer seems to depend on a lot
>> more than just the source code submitted.
>
> C is a family of languages with many dialects. An almost fifty-year-old
> family. C++ is a C dialect. Objective C is a C dialect.
>
> What does your question mean?
>
> Does your question mean "is this program a valid program in absolutely
> any C dialect that has ever existed, such that all its externally
> visible behaviors are the same?"

Oh, FFS. We're not talking about C++, or Objective C.

But tell me what dialect of C my 'int fred(void){}' is a valid program
of. Then tell me why most C compilers are still compiling that dialect
by default in 2023.

And now tell me what dialect of C I need for that to be an INvalid program.

It sounds like you're clutching at straws to excuse all this crassness.

Fortran has been around longer than C. Do its latest compilers give
priority to being able to build code unchanged from the 60s and 70s?

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 21:46, Kaz Kylheku wrote:
>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>> MY compilers check that an input sourcefile for language L has a valid
>>> syntax,
>>
>> Which valid syntax? As of the last night's commit which added new
>> syntax?
>>
>> What if I have code that uses last year's syntax, and for the
>> time being want to keep it that way (not have newer syntax
>> creeping in accidentally?)
>>
>> Oh shit! Look, someone likes your language and has written their
>> own implementation. It has a few differences and extensions.
>> Users are starting to use them and complaining they don't work
>> in the original.
>>
>> Do you support those, unconditionally?

Not good at answering the tough questions.
>>
>>> can fully resolve name references, obeys the type rules of the
>>> language, and does various other bits and pieces.
>>
>> Do your compilers target PPC? I have a project that runs on big endian
>> PPC64. Also ported it to Loongarch: this new ISA from China.
>>
>> SPARC? MIPS? RISCV?
>>
>> Oh wait yes; thanks to GCC ...
>>
>>> So how does gcc manage to do pretty much what it likes, including either
>>> compiling a program with no errors or warnings, or compiling the SAME
>>> PROGRAM with fatal errors?
>>
>> By supporting forty years of C revisions, plus its dialect, plus having
>> flexible code generation and diagnosis options, that the users want and
>> depend on.
>
> So you freely admit that C is a mess, and so are its compilers.

Absolutely.

> And yet, it is possible to create a compiler that gives the common-sense
> results that one would expect.

That no one's actual production code base would expect, but go on.

> What do you expect the results of compiling this program with -c to be:
>
> int fred(void){}
>
> Here are the results I get:
>
> Warnings Errors
>
> gcc - -
> tcc - -
> clang 1 -
> msvc 1 -
> gcc -Wall 1 -
> lccwin32 1 -
> bcc - 1
>
>
> The problem with that function, in case you haven't spotted it, is that
> it does not return an 'int' value.

That's a noteworthy fact. If a caller tries to use the return
value, there is a problem.

The C dialect/descendant which makes this an error is C++.

> Yet, not one of those compilers other than bcc stops you creating an
> executable containing a call to that function.

ISO C doesn't require implementations to fail to translate a program,
even if it contains syntax errors and constraint violations that a
conforming implementation must diagnose.
>
> That can be serious, especially if the return type was a pointer.
>
> This is just incredible. You can spout all the nonsense you like about
> the long history of C, but there is no excuse for a compiler in 2023 to
> pass code like that with default behaviour.

There is no excuse for a software engineer to be using a compiler
with default behavior. Not in 2023 or 1993.

> You have to give gcc -Wall to even get it to warn.

So why dontcha?

Wait, check this out. I can out-complain you!

You have to give gc **another c** before it even accepts C programs. That's
how much of a mess it is!

Here is what I get on Ubuntu 18:

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

int main(void)
{ puts("hello, world!");
return 0;
} $ gc hello.c
Error: hello.c: syntax error in line 3 near 'int'
$ gcc hello.c
$ ./a.out
hello, world!

Incredible! gc, in its default mode, cannot recognize a valid C program;
emitting bogus diagnostics. We have to add another c.

How do they live with it?

> Yet, everyone here will either defend it to the death, or just brush it
> off and say, Of couse, you have to provide the right options to get the
> compiler to do its job properly.
>
> (BTW, which option do you need to force a hard error on that program,
> which doesn't also fail on unused lables?)

$ gcc -Wall falloff.c -c
falloff.c: In function ‘func’:
falloff.c:1:18: warning: label ‘label’ defined but not used [-Wunused-label]
int func(void) { label: ; }
^~~~~
falloff.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
int func(void) { label: ; }
^~~

Okay, GCC's friendly diagnosis is telling me that the first warning
is the result of -Wunused-label. Thus:

$ gcc -Wall -Wno-unused-label falloff.c -c
falloff.c: In function ‘func’:
falloff.c:1:1: warning: control reaches end of non-void function [-Wreturn-type]
int func(void) { label: ; }
^~~

Full disclosure: I'm an idiot too, but I have a nephew here who is
starting grade 5 next week who helped me with this!

By the way, in human-written code, you probably want to remove
unused labels.

In generated code, get all your diagnostics from your own front-end,
and operate the C compiler quietly.

> I would say, WHY doesn't it do its job anyway? WHY doesn't it operate in
> a safer mode by default?
>
> I can get my bcc to pass that program, but I have to specify -old, and
> that is only so that existing can be compiled.

-old? What a mess, it's like you have multiple languages in one.

Which one is the real one?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 22:09, Kaz Kylheku wrote:
>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>> On 01/09/2023 19:49, Kaz Kylheku wrote:
>>>> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>>>>> Is my program correct? Apparently gcc can't tell me; *I* have to tell
>>>>> *it*. You pretty much say that above.
>>>>
>>>> GCC can't tell you whether a program is correct, because it can't read
>>>> your requirement specification, high level design or detailed design.
>>>> It doesn't run your program, let alone execute test cases on it.
>>>>
>>>>> OK, *I* say then that if 'gcc prog.c' works with no notes, warnings or
>>>>> messages, then my program is fine.
>>>>
>>>> Even if ./a.out segfaults? Yes, if the requirement specification
>>>> for the program is "write me small program that segfaults on Unix".
>>>> It would then be incorrect if it terminated normally.
>>>>
>>>
>>> Ok, since you seem determined to misunderstand.
>>
>> It's you who don't understand what "correct" means.
>>
>> When you start talking about correctness, the program's specification
>> is involved.
>>
>> In fact that is all that is involved. A null pointer dereference
>> or division by zero become correct if the specification says so.
>>
>>> Is my program a valid C program? The answer seems to depend on a lot
>>> more than just the source code submitted.
>>
>> C is a family of languages with many dialects. An almost fifty-year-old
>> family. C++ is a C dialect. Objective C is a C dialect.
>>
>> What does your question mean?
>>
>> Does your question mean "is this program a valid program in absolutely
>> any C dialect that has ever existed, such that all its externally
>> visible behaviors are the same?"
>
> Oh, FFS. We're not talking about C++, or Objective C.

Those are dialects of C. A program that doesn't compile as C++
isn't "valid C" by the definition of valid in any dialect whatsoever.

> But tell me what dialect of C my 'int fred(void){}' is a valid program
> of.

Right off the bat, it's not valid in anything that is before ANSI C.
Only compilers implementing ANSI C, or at least draft features of ANSI
C, would acdept (void), which is an ANSI C invention.

There are too many dialects of C, including ones I've never heard of, in
which that is potentially valid.

It is valid in C90 and in C99.

> Then tell me why most C compilers are still compiling that dialect
> by default in 2023.

Until quite recently, GCC defaulted to "gnu89": a GNU C dialect
resembling C90/ANSI C. I think it might now be handling "gnu99"
instead.

The C99 dialect of C is very popular; there is a lot of code written
in it.

A dialect based off c99 isn't a bad default choice.

(I think it would be better for gcc to refuse to do anything unless
the dialect is specified.)

> And now tell me what dialect of C I need for that to be an INvalid program.

I don't think the function requires a diagnostic in any standard C
dialect. There is no error unless the caller tries to capture the
return value.

Pretty much any gcc dialect, if given the -Werror=return-type
option rejects it.

That's included in -Wall, so if you use -Werror-all you get that
dialect also.

If you don't want that kind of code in your code base, there
is a solution.

> Fortran has been around longer than C. Do its latest compilers give
> priority to being able to build code unchanged from the 60s and 70s?

I strongly suspect, yes.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2023-09-01, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> By default, the object file name for a source file is made by
>> replacing the suffix .c, .i, .s, etc., with .o.
>
> I agree that's potentially misleading. I think the intent was that
> "object file name" is intended to refer just to the file *name*, not the
> full file *path*.

Ah, but I have a piece of trivia for you:

_GNU Coding Standards_, July 1, 2021:

Please do not use the term “pathname” that is used in Unix
documentation; use “file name” (two words) instead. We use the term
“path” only for search paths, which are lists of directory names.

GNU programs and documentation are supposed to use file name
to refer to a path with multiple components too, not just one
component.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> Until quite recently, GCC defaulted to "gnu89": a GNU C dialect
> resembling C90/ANSI C. I think it might now be handling "gnu99"
> instead.
[...]

Recent versions of gcc default to "-std=gnu17".

--
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:
[...]
> But tell me what dialect of C my 'int fred(void){}' is a valid program
> of. Then tell me why most C compilers are still compiling that dialect
> by default in 2023.
[...]

Can you clarify what point you're making with `int fred(void){}`?

That's a valid function definition and translation unit in every version
of ISO C going back to C90, by which I mean that it does not violate any
constraint or syntax rule. (I presume we're not concerned with K&R C,
which didn't have void.) It is not a valid *program* for a hosted
implementation in any version of C, since it lacks a `main` function.

A compiler may reasonably warn about the fact that control reaches the
end of a non-void function, but the standard doesn't require a
diagnostic. Calling `fred` and not using the result is well defined.
Calling `fred` and attempting to use the result has undefined behavior.
No diagnostic is required, up to and including C23. (There are
historical reasons for this, which I won't go into.)

Note carefully that I am describing the requirements given by the C
standard, not expressing an opinion on whether they're good or bad.

Now, what was your point, and how does `int fred(void){}` illustrate it?

--
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 01/09/2023 19:07, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 01/09/2023 14:53, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 01/09/2023 13:08, Richard Harnden wrote:
>>>>>> On 01/09/2023 12:01, Bart wrote:
>>>>
>>>>>>> We are talking about compilers like gcc where you make up your own rules
>>>>>>> as to show strictly you want your program treated:
>>>>>>>
>>>>>>>   gcc prog.c              zero warnings, writes .exe
>>>>>>>   gcc @options prog.c     10000 warnings, but it still writes .exe
>>>>>>>   gcc @options prog.c     10000 warning and 1 error, no .exe
>>>>
>>>> Which would you choose as the one and only behaviour?
>> No answer? I'll look at the rest of your post, if you decide to address
>> this point...

> You want an answer, I'd go with the first, since then the three compilers I
> use the most work the same way.
>
> That's not completely satisfactory,

It's totally unacceptable to me and, I suspect, a lot of other people.
I usually don't want gcc extensions and I want to be able specify the
ISO C standard to use at the very least. But I also want as much help
spotting errors as the compiler can give me.

> since there are aspects of the C language I think are too unsafe, but:
>
> * Have to be passed because they are legal C
>
> * Cannot reliably be detected by a compiler
>
> * Are too extensively used in legacy code to be just outlawed.

Yet you want to stop people from having hundreds of helpful diagnostics.

I suspect you don't mean what you seem to have said -- that gcc should
always behave in it's default mode. But if that is not what you meant
to say then you have not answered the question at all.

You say, dismissively, that one can "make up ones your rules" with gcc,
so I am asking for you to say exactly what you don't want me to be able
to ask for in terms of checking and/or its absence. Just how crippled
and annoying would I find gcc to be if you were in charge? How much
choice will you take away?

--
Ben.

On 02/09/2023 00:02, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>> of. Then tell me why most C compilers are still compiling that dialect
>> by default in 2023.
> [...]
>
> Can you clarify what point you're making with `int fred(void){}`?
>
> That's a valid function definition and translation unit in every version
> of ISO C going back to C90, by which I mean that it does not violate any
> constraint or syntax rule. (I presume we're not concerned with K&R C,
> which didn't have void.) It is not a valid *program* for a hosted
> implementation in any version of C, since it lacks a `main` function.
>
> A compiler may reasonably warn about the fact that control reaches the
> end of a non-void function, but the standard doesn't require a
> diagnostic. Calling `fred` and not using the result is well defined.
> Calling `fred` and attempting to use the result has undefined behavior.
> No diagnostic is required, up to and including C23. (There are
> historical reasons for this, which I won't go into.)
>
> Note carefully that I am describing the requirements given by the C
> standard, not expressing an opinion on whether they're good or bad.
>
> Now, what was your point, and how does `int fred(void){}` illustrate it?

I would have said it's obviously wrong.

But in this group, so many people have argued that black is white, or
vice versa, that nothing surprises me any more.

Imagine buying a car with no brakes. Oh, nothing wrong that, only if you
were to actually use the brakes! Then, it would have been up to me to
insist on having brakes in the first place, something I wouldn't have
thought was my responsibility.

This either really is that crazy, or everyone is in on a conspiracy to
wind me up.

> A compiler may reasonably warn about the fact that control reaches the
> end of a non-void function,

Why only warn? This should be a hard error. Fix it and move on.

> Calling `fred` and not using the result is well defined.

People say C is unsafe. Yes it is, but this nonsense makes it extra
unsafe for no good reason.

Suppose fred() is part of a library. Then who knows what code will be
calling it and whether that value is expected.

What possible point, what advantage, is there in defining a function's
return type, but not providing any value?

Look, I promised this guy I would overhaul at my C compiler. Fortunately
the task is interesting, and for now, it doesn't involving dealing with
much C code.

Otherwise, this crazy language, crazy compilers, crazy tools and the
crazy opinions of its adherents are seriously doing my head in.

I've given staggeringly bad examples of each, but nobody is fazed.
There's always some excuse. And if there is no actual reason, it's
because it's how it worked in 1974 so it has to be like that for eternity.

I'm going back to my own saner language and compilers that don't beat
about the bush:

func fred:int =
end

"Return value missing"

I can't proceed until I provide one, or change it to a function that
doesn't return a value.

Is there ... anything wrong with that?

On 2023-09-02, Bart <bc@freeuk.com> wrote:
> On 02/09/2023 00:02, Keith Thompson wrote:
>> Now, what was your point, and how does `int fred(void){}` illustrate it?
>
> I would have said it's obviously wrong.
>
> But in this group, so many people have argued that black is white, or
> vice versa, that nothing surprises me any more.

It's a good idea to produce a diagnostic in cases when it's obvious
that the control graph of the function reaches the end without
hitting a return statement.

C allowing the return, provided that the caller doesn't use the
value, is a bit of a relic. Early C worked that way because
every function returned int, but not every function needed
to return anything. It's not a good feature today.

Keith seems to have mentioned that something had been done about it
in C23?

Anyway, compilers can diagnose it even though it's not required.

It would be significantly more difficult to work with C without
compilers that go beyond required diagnostics.

You can't just blindly diagnose this as a syntactic issue; i.e.
that the last statement of a function which returns a value isn't
a return statement.

We don't want this diagnosed:

int fred(void)
{
if (this)
return that;
else
return other;
}

Basically we want the last statement to to be a "tail statement",
which is defined as a return statement, or else a statement which
has a tail statement in every tail position.

The body of a loop is a tail statement if there is no break or goto out
of it.

A loop is a tail statement if its guard is a constant expression
evaluating to true.

A function call is a tail statement if it calls a function known
not to return: abort(), longjmp(), exit() and some others.

> Imagine buying a car with no brakes. Oh, nothing wrong that, only if you

Imagine buying a power transistor with no thermal shutoff.

Wait, that's pretty much all of them.

Engineering products and consumer products are different.

A transistor has good reasons for being the way it is; a language
allowing control flow to fall off the end without a return value
isn't such a good reason. We can't compare the justification.

It's still an engineering tool with a "safe operating area"
that you have to observe, and not comparable to a consumer product.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Saturday, 2 September 2023 at 01:14:36 UTC+1, Ben Bacarisse wrote:
> Bart <b...@freeuk.com> writes:
>
> > On 01/09/2023 19:07, Ben Bacarisse wrote:
> >> Bart <b...@freeuk.com> writes:
> >>
> >>> On 01/09/2023 14:53, Ben Bacarisse wrote:
> >>>> Bart <b...@freeuk.com> writes:
> >>>>
> >>>>> On 01/09/2023 13:08, Richard Harnden wrote:
> >>>>>> On 01/09/2023 12:01, Bart wrote:
> >>>>
> >>>>>>> We are talking about compilers like gcc where you make up your own rules
> >>>>>>> as to show strictly you want your program treated:
> >>>>>>>
> >>>>>>> gcc prog.c zero warnings, writes .exe
> >>>>>>> gcc @options prog.c 10000 warnings, but it still writes .exe
> >>>>>>> gcc @options prog.c 10000 warning and 1 error, no .exe
> >>>>
> >>>> Which would you choose as the one and only behaviour?
> >> No answer? I'll look at the rest of your post, if you decide to address
> >> this point...
> > You want an answer, I'd go with the first, since then the three compilers I
> > use the most work the same way.
> >
> > That's not completely satisfactory,
> It's totally unacceptable to me and, I suspect, a lot of other people.
> I usually don't want gcc extensions and I want to be able specify the
> ISO C standard to use at the very least. But I also want as much help
> spotting errors as the compiler can give me.
>
Generally gcc in default mode gives sensible warnings which either indicate
actual bugs, or odd programming which should be cleaned up. Then you can
ramp up the warning level to get a huge amount, but they tend to be things
like warnings about mixed mode arithemetic because size_t is unsigned,
which is very unlikely to cause an error.
>
> > since there are aspects of the C language I think are too unsafe, but:
> >
> > * Have to be passed because they are legal C
> >
> > * Cannot reliably be detected by a compiler
> >
> > * Are too extensively used in legacy code to be just outlawed.
> Yet you want to stop people from having hundreds of helpful diagnostics.
>
> I suspect you don't mean what you seem to have said -- that gcc should
> always behave in it's default mode. But if that is not what you meant
> to say then you have not answered the question at all.
>
> You say, dismissively, that one can "make up ones your rules" with gcc,
> so I am asking for you to say exactly what you don't want me to be able
> to ask for in terms of checking and/or its absence. Just how crippled
> and annoying would I find gcc to be if you were in charge? How much
> choice will you take away?
>
In most software, every option you provide represents a failure rather than
an enhancement. It's often a symptom of sloppy design - a lot of functions
need parameterising, and instead of doing the hard work and finding the
parameters to use, the designer just gives the job to the user. It's often a
symptom of design by programmers rather than user-interface people.
Programmers don't mind -gamma-correction=1.1, but it's a nightmare to
someone who just wants to watch telly. I suppose you could argue that a
compiler is an exception to the general rule that programmers shouldn't design
interfaces.
But the general rule is that options make a program easier to write and harder
to use. Sometimes the gain in ease of writing is so large that a small loss
in ease of use has to be tolerated. And of course there is the issue of what is
an "option" and what is a regular instruction to the program that inherently
has to come from the user.
But basically a compiler should translate C source to object code. That's
all it should do. And it shouldn't need telling how to do that.

On 2023-09-02, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> Generally gcc in default mode gives sensible warnings which either indicate

For values of "default mode" being -Wall, of course.

> In most software, every option you provide represents a failure rather than
> an enhancement. It's often a symptom of sloppy design - a lot of functions
> need parameterising, and instead of doing the hard work and finding the
> parameters to use, the designer just gives the job to the user. It's often a
> symptom of design by programmers rather than user-interface people.

But that's what a programming language is.

The vendor describes some assembly language instructions described in
the data sheet for the chip, effectively punting to the user the
task of deciding which ones to select in order to have it Pac Man.

A piano is nothing but sloppy design; you have to pick a sequence
of correct notes out of 88 keys. At least they have player pianos
though.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Bart <bc@freeuk.com> writes:
> On 02/09/2023 00:02, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> But tell me what dialect of C my 'int fred(void){}' is a valid program
>>> of. Then tell me why most C compilers are still compiling that dialect
>>> by default in 2023.
>> [...]
>> Can you clarify what point you're making with `int fred(void){}`?
>> That's a valid function definition and translation unit in every
>> version
>> of ISO C going back to C90, by which I mean that it does not violate any
>> constraint or syntax rule. (I presume we're not concerned with K&R C,
>> which didn't have void.) It is not a valid *program* for a hosted
>> implementation in any version of C, since it lacks a `main` function.
>> A compiler may reasonably warn about the fact that control reaches
>> the
>> end of a non-void function, but the standard doesn't require a
>> diagnostic. Calling `fred` and not using the result is well defined.
>> Calling `fred` and attempting to use the result has undefined behavior.
>> No diagnostic is required, up to and including C23. (There are
>> historical reasons for this, which I won't go into.)
>> Note carefully that I am describing the requirements given by the C
>> standard, not expressing an opinion on whether they're good or bad.
>> Now, what was your point, and how does `int fred(void){}` illustrate
>> it?
>
> I would have said it's obviously wrong.

Reading the rest of your reply, it takes you several paragraphs to get
around to saying *why* it's "obviously wrong". You think it's obviously
wrong because it's defined to return a non-void, but it does not do so.

I mentioned that there are historical reasons why this is not a fatal
error. I've probably discussed those reasons here before, though not in
this thread. If I thought you were interested in learning something,
I'd be glad to do so again. If someone else asks I'll explain it to
them, and you can read along if you like.

It is a fact that `int fred(void){}` does not, according to any edition
of the ISO C standard, require a diagnostic. It does not violate any
syntax rule or constraint.

I don't know how to make it any clearer that I was explaining to you
what the standard says, not expressing or soliciting an opinion about
it.

> But in this group, so many people have argued that black is white, or
> vice versa, that nothing surprises me any more.

If you're saying that I'm wrong about what the standard says, I'm
interested in hearing why.

Am I wrong about what the standard says?

If you're saying that you don't like what the standard says, I'm aware
of that and profoundly uninterested in discussing it with you.

And of course gcc can be made to warn about it with the right options.

[...]

> I'm going back to my own saner language and compilers that don't beat
> about the bush:
>
> func fred:int =
> end
>
> "Return value missing"
>
> I can't proceed until I provide one, or change it to a function that
> doesn't return a value.
>
> Is there ... anything wrong with that?

No, and I have never said or implied that there is. But you know that.

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

Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> C allowing the return, provided that the caller doesn't use the
> value, is a bit of a relic. Early C worked that way because
> every function returned int, but not every function needed
> to return anything. It's not a good feature today.
>
> Keith seems to have mentioned that something had been done about it
> in C23?

No, it's the same in C23.

N3096 6.9.1p12:

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

I think the "unles otherwise specified" refers to the special case rule
for falling off the end of main().

> Anyway, compilers can diagnose it even though it's not required.
>
> It would be significantly more difficult to work with C without
> compilers that go beyond required diagnostics.
>
> You can't just blindly diagnose this as a syntactic issue; i.e.
> that the last statement of a function which returns a value isn't
> a return statement.
>
> We don't want this diagnosed:
>
> int fred(void)
> {
> if (this)
> return that;
> else
> return other;
> }
>
> Basically we want the last statement to to be a "tail statement",
> which is defined as a return statement, or else a statement which
> has a tail statement in every tail position.
>
> The body of a loop is a tail statement if there is no break or goto out
> of it.
>
> A loop is a tail statement if its guard is a constant expression
> evaluating to true.
>
> A function call is a tail statement if it calls a function known
> not to return: abort(), longjmp(), exit() and some others.
[...]

To put it another way, the closing } of a non-void function (other
than main()) should be unreachable.

When C was first defined, and probably as late as 1989, it would
(arguably) have been unreasonable to require all C compilers to
do the kind of analysis needed to enforce this. Some more modern
languages do have requirement like this.

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