On 02/09/2023 23:52, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 02/09/2023 01: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.)
>>
>> Also note that it is perfectly fine to have :
>>
>> int fred(void) { }
>>
>> int boo(void) {
>> int x = fred();
>> return x + 1;
>> }
>>
>> There is nothing in this code that is undefined behaviour - it's all
>> valid C. There is only a problem - undefined behaviour - if the
>> program actually /calls/ "boo".
>
> It's "perfectly fine" only in the sense that it doesn't violate
> a constraint or syntax rule and doesn't cause undefined behavior
> unless it's called. It's still bad code.

Yes.

>
> I wouldn't mind if a future edition of the C standard added a
> requirement that the } of a non-void function must be unreachable
> (with an exception for main()). There are languages that have such
> a requirement, and in my limited experience it works pretty well.

I would not mind that at all either. I don't think it will ever happen.
Backwards compatibility, and the general conservativism of C standards
makes it highly unlikely. It is also not an error that is likely to be
common - or at least, not something that is likely to occur without all
sorts of other messes in code written by someone with little knowledge
or regard for good code.

>
> The problem is that such a requirement requires the compiler
> to perform control flow analysis that's not otherwise required.

Indeed. And even with advanced flow analysis, there will always be
cases where it is impractical to determine if the returns are correct.

> Most large modern compilers already do such analysis for optimization
> and diagnostic purposes; at most they might have to enable it
> at all optimization levels. Small "hobby" compilers might have
> to do some extra work -- but such compilers often aren't fully
> conforming anyway.

Yes. Often even big compilers don't do appropriate analysis unless you
ask for it - "gcc -Wall" is much more limited without "-O1" or "-O2".
(I'd rather "-Wall -O2", or something close to that, were the default
for gcc - but I know that's highly unlikely to change.)

>
> Such a requirement would have been a more substantial burden when
> the language was originally being defined, and inertia probably
> has a lot to do with why it hasn't been imposed since then.
>

Yes.

> I think we'd need a rigorous definition of reachability that's not too
> difficult to implement. It might require adding unnecessary return
> statements in some corner cases, but IMHO that's ok. There's precedent
> in other languages that C could steal.
>

I think it's better to leave that to other languages. A key feature of
C is that it does not change much. It would be difficult to "fix" C
(even if people could agree on what needs fixing) without simultaneously
breaking C.

> Simply requiring a non-void function to have a return statement
> *somewhere* would be far less helpful, and would not be worth the
> effort. It would allow such obviously incorrect code as:
>
> int fred(void) {
> if (condition) return 42;
> }
>

Agreed.

On 03/09/2023 15:31, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> Take this program:
>>
>> void fred(void){}; void bill(void)
>
> This program has two syntax errors.

Sorry, I found that when I tested the above but forgot to update the post.

> The one you are talking about and
> the missing ; or missing compound statement as the end of the line.
>
>> There's an extraneous ";" that the grammar says shouldn't be there, so it's
>> a syntax error.
>>
>> Should a compiler fail it or not?
>
> The standard says that it should be reported.

And yet the first four compilers I tried don't do that.

>> Most compilers say nothing, or at best can be coaxed into a warning.
>
> More rhetorical spin. For gcc and clang (to take tho I can easily test)
> if you ask them to check for standard C syntax,
Clearly, many people don't do so. Or if they do, they ignore the warnings.

> they both tell you the ;
> should not be there.

But, they will still produce an executable. Not much of an incentive is it?

Both, by default, implement a whole bunch of
> extensions. It's not "coaxing" to tell a tool to do what you want.

The upshot is that there will still be codebases that may contain that
extra ";", which can bite later when compiled more strictly.

With my suggestion to fix it at an early stage, no codebase created
using that approach will have the extra semicolon.

This is a trivial infringement of syntax. But if the grammar says it's
wrong, then let the compilation fail.

In C, semicolons are critical: an extra or missing semicolon in
executable code can lead to serious bugs. So encourage discipline it
getting them right.

This current approach of not particularly caring seems all too typical.

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

> On Saturday, 2 September 2023 at 23:28:30 UTC+1, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>> > 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.
>> I don't find that to be the case.
>> >> 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.
>>
>> Interfaces should be designed for the target users. It is a nuisance to
>> me that most GUI programs are not designed for people like me as the
>> target user.
>>
>> Trivial example: the default PDF reader on my system is very capable,
>> but of course I can't search for a regular expression as that would
>> confuse the other users. Ditto the web browser.
>>
> Exactly. Regular expressions are too hard to use. Unless you happen to
> be a programmer. In fact they're too hard for me to use - I seldom
> work with text so I almost never use regular expressions. Where I do
> it's a case of looking up the syntax.

I am not sure what part of my remark you are agreeing with. I'll take
it that you agree that I am not well-catered for by modern
"well-designed" user interfaces.

>> There was a time when users like me were better catered for. There
>> were, in some desktop systems, "hidden" options to turn on some or all
>> of this sort of "advanced stuff", but even this seems to be going out of
>> fashion.
>>
> Because programmers write programs, they often design user interfaces.
> However large professional software companies employ ergonomics
> experts, taking that job away from the programmers.

Ergonomics experts often design interfaces that I find hard to use. To
take one example, I want to use common key binding across applications,
but the experts seem to think there is only one such set (and it comes
from an OS I have not used for years), so I can't use the bindings my
fingers "know" about.

There are probably a few UI experts who really do know how to design
easy to use, powerful interfaces that suit a wide rage of users with
differing expectations and experience, but most of them just know how to
make easy tasks easy for the most commonly encountered users.

> So as you say,
> "advanced" options are often culled. All it takes is for the user to somehow
> acidentally set the program into advanced mode, and he can't use it, and
> that's an expensive call to technical support.

Yes, I know why it happens. Apparently, though, a solution that
prevents accidents is beyond the wit of ergonomics experts. An expert
who knows how to make tasks easy, should also know how to make some
things well-nigh impossible by accident.

>> > I suppose you could argue that a compiler is an exception to the
>> > general rule that programmers shouldn't design interfaces.
>>
>> However it is covered by the better rule that interfaces should suit the
>> target users. You can't satisfy everyone, of course, but people writing
>> C programs have very different requirements to people watching television.
>>
> No-one is going to deny that interfaces should suit the target users. But
> whilst true, it's not helpful. "Programmers shouldn't design interfaces"
> is more controversial (often they do, often there is no choice because unlike
> Microsoft, you are to small to have a "usability lab" all products have to
> go through) . So that makes it worth saying.

But it says very little because "programmers" are not a uniform group.
For example, the HCI research team I used to work alongside was almost
entirely made up of people who could be described as programmers. Sure,
they were also psychologists, linguists and graphic designers, but they
all had top-notch programming skills as well.

>> > But the
>> > general rule is that options make a program easier to write and harder
>> > to use.
>>
>> I suspect that's one of your "general rules" where every suggested
>> exception would be waved away, so instead I'll ask for your best
>> example. What is, in your mind, the archetypal program that is easier
>> to write and harder to use because of the options? That would help me
>> to understand what point you are making here.
>>
> OK, let's take optimisation.
> If I were specifying a compiler, I'd say, "I want optimisation to be so fast
> that there is no noticeable diference between the speed of optimised and
> non-optimised builds. And I want stack trace information to be attached to
> the optimised build with no noticeable impact on the speed of execution,
> and for that information to be encrypted so that it doesn't assist reverse
> engineering".
....
> So, reluctantly, I agree that I can't have what I want. So we'll need
> an option. Debug mode and release mode, maybe more.

I see. Now I know what you were getting at: options are sometimes a
consequence of impossible specifications. That's not an interesting
observation (to me) but it certainly does not constitute a general rule
about programs.

--
Ben.

Bart <bc@freeuk.com> writes:

> On 03/09/2023 02:28, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 02/09/2023 22:42, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>
>>> I understand the point about the void* result type needing to match a set
>>> of other functions.
>> No, void * is the actual type I wanted. It was not being used as a
>> point "to any object". Mind you, the return has nothing to do with the
>> point of the post.
>
> Then I /don't/ understand. Why not just make it a 'void' function?
>
> I had assumed the address of no_op was used in a table of function pointers
> sharing a void* return type.

Yes, but exactly what that type is is not the point. All the functions
have the same type and a non-void return type.

>>> But how much of an imposition is it to supply a 'return
>>> NULL' line at the end?
>> Not much, but why should I add pointless junk?
>
> And yet, some people are happy to add attributes like _Noreturn. Some are
> also happy to write 'i' three times in a simple for-header.

C programmers have no choice. You can't conflate a reluctance to moan
alongside you with happiness about everything.

But worse, even if I /were/ happy about redundancy in some cases, you
should not assume that I will be happy about all redundant code.

> /You/ are even happy to write a return type that doesn't correspond to the
> function body.

No. You may not understand the point of the example, but just ask more,
don't assume.

Let me try again... All the functions have the same type. For all of
the functions that will be called, the return value is used (and the
arguments passed will be used as well).

I wanted a value to store, like a null pointer, to indicate that
something is wrong -- that a pointer has not been correctly set to a
proper, usable, function pointer value. Initially I used a null
pointer, but then I'd just get a crash if it a program bug caused it to
be called. Instead, I decided to use a pointer to a function of the
same type as all the others. And it makes sense that it should report
an error if it were, in fact, called as a result of some bug in the
program.

Now all the pointer variables always have a valid pointer and I can
still tell if one is not yet set correctly by testing ptr == no_op.
(Actually that might have been a bad name for the example. The actual
function was called 'not_set'.)

>>> Then it doesn't matter what precedes it; that exit line could could be
>>> commented out, it can be changed, or it's to be maintained by someone
>>> else.
>>
>> And then the function would be incorrect. The exit (with a message
>> output by the error function) is there for a purpose. If I (or someone
>> else) were to comment it out (by accident, presumably) I /want/ a
>> warning from gcc that the function won't return a value.
>
> This is what I've complained that it doesn't do.

You know that it will, though, so this is just the same old gripe.

>> If I follow
>> your advice, nothing will alert me that I've commented out the key part
>> of the function.
>
> I can't win this can I? Obviously if you comment out swathes of code, the
> behaviour will change.

You can't win this one point because you are wrong.

void *not_set(int) {
exit(error("should not happen"));
}

is better than

void *not_set(int) {
exit(error("should not happen"));
return NULL;
}

because (a) the latter has redundant code, and (b) if, as you suggest
might happen, I or someone else comments out the exit call your version
will not result in a diagnostic whereas mine will (in part because I
know how to use gcc).

--
Ben.

David Brown <david.brown@hesbynett.no> writes:
>On 01/09/2023 20:59, Scott Lurndal wrote:
>> 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 )
>>
>
>Or even better, since this is a pragma in the source code, have it
>wrapped in conditional compilation that checks first for gcc, then for
>the gcc version. Sure, it can be a bit ugly, but it only needs to be
>written once and copied out verbatim by the code generator (or put in a
>common header file for the rest of us), and godbolt.org makes it very
>easy to test with different gcc versions.
>

Generally I tend to eschew conditional compilation[*]. Not only is it
unattractive, it also significantly increases the verification burden
(multiplied by the number of predicates) and decreases significantly
the readability and maintainability of the code.

I've seen code where every fourth line is #if. Completely
unreadable and very difficult to amend.

[*] With the occasional exception isolated to a header file.

On 03/09/2023 15:02, David Brown wrote:
> On 02/09/2023 20:53, Bart wrote:

>> What exactly are the consequences of requiring programs to satisfy my
>> compiler regarding 'return'? Virtually one. But it would then be
>> impossible to write a function without a proper return value.
>>
>
> You live in such a small bubble!  Don't you ever feel the need to look
> outside, or at least /think/ a bit about the rest of the world?

What's wrong with that?

This discussion about minor points of design in C is interesting, but to
me academic. This particular issue is:

* A reluctance to write 'return x;' in a value-returning function

* A desire for a compiler to turn a blind eye to that end, despite
omitting such a return being bad news for 99% of functions

* So leaving it pretty much a choice for the user whether they write it,
and whether a compiler reports it.

All stuff I consider sloppy, lax, and irresponsible.

My language deals with this in other ways:

* I can simply omit 'return' and just have the value

* That also allows me to have a function myexit() which returns a
suitable value, so nothing (no dummy 'return x' or even 'x') is needed

* I can choose to use 'stop n' to terminate. Here the compiler knows
control can't proceed past this statement, and can suppress the
error, or cause 'stop' to yield the value needed. (I haven't done
this, but could.)

So I can do both things at once: have a stricter, safer language, and
not have to write a full 'return x' that I know will not be executed
(although I'm not that bothered by it).

Now let's turn things around: can I write, in my language, a
value-returning function that returns without a value (that is, whatever
happens to be left over in a register)?

In C:

void* fred(void) {
(long long int)rand()*3.14159;
}

int main(void) {
printf("%p\n", fred());
printf("%p\n", fred());
}

The output varies considerably between 'bcc -old' and tcc/gcc. It is UB.

So in C is it really not very hard, actually surprisingly easy; too
easy: not a peep from the compiler invoked in what is likely the most
common way.

But in my language I can't it:

func fred:ref void =
int(rand()*pi)
end

proc main=
println fred()
println fred()
end

(Type conversion error.) No doubt you will argue C is superior here.

Sure, then ASM is even more superior!

Anyway, my view is that it is you who live in more of a bubble, even if
a very large and complex one! I at least can look outside C at my
languages which are of the same rank, and compare how they approach
common problems.

I acknowledge that it is easy for me to try new things, but that itself
allows me to say whether they are better than how C does it, or worse.
(Usually the former! The others don't last long.)

You can't that because there is nothing to compare with except languages
at a very different level.

On 03/09/2023 17:54, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 01/09/2023 20:59, Scott Lurndal wrote:
>>> 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 )
>>>
>>
>> Or even better, since this is a pragma in the source code, have it
>> wrapped in conditional compilation that checks first for gcc, then for
>> the gcc version. Sure, it can be a bit ugly, but it only needs to be
>> written once and copied out verbatim by the code generator (or put in a
>> common header file for the rest of us), and godbolt.org makes it very
>> easy to test with different gcc versions.
>>
>
> Generally I tend to eschew conditional compilation[*]. Not only is it
> unattractive, it also significantly increases the verification burden
> (multiplied by the number of predicates) and decreases significantly
> the readability and maintainability of the code.
>
> I've seen code where every fourth line is #if. Completely
> unreadable and very difficult to amend.
>
> [*] With the occasional exception isolated to a header file.

I agree with your practice here. But one place where I think it does
work well, is for such compiler-specific features. And yes, you put it
all in a header file. In my business, it's not uncommon to see a header
such as :

// intrinsics.h
#ifdef __GNUC__
#include "gcc_intrinsics.h"
#endif
#ifdef __IAR__
#include "iar_intrinsics.h"
#endif

etc.

Bart <bc@freeuk.com> writes:

> On 03/09/2023 15:02, David Brown wrote:
>
>> On 02/09/2023 20:53, Bart wrote:
>>
>>> What exactly are the consequences of requiring programs to satisfy
>>> my compiler regarding 'return'? Virtually one. But it would then be
>>> impossible to write a function without a proper return value.
>>
>> You live in such a small bubble! Don't you ever feel the need to
>> look outside, or at least /think/ a bit about the rest of the world?
>
> What's wrong with that?

Nothing wrong with living in a bubble. What's wrong is acting
like what people inside the bubble (ie, you) want is the same
as what people outside the bubble want. Stop acting that way
and people will stop complaining. Duh!

On 2023-09-03, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>> I wouldn't mind if a future edition of the C standard added a
>> requirement that the } of a non-void function must be unreachable
>> (with an exception for main()). There are languages that have such
>> a requirement, and in my limited experience it works pretty well.
>>
>> The problem is that such a requirement requires the compiler
>> to perform control flow analysis that's not otherwise required.
>> [...]
>
> The problem is that in C such a determination cannot be made
> precisely, for reasons that are both theoretical and practical.
> Only heuristics are possible, but requirements in the C standard
> are never stated in terms of heuristics (and rightly so).

I believe this is false on both counts.

There is nothing imprecise about "heuristics". What heuristics
aren't is "accurate". They are precise rules that substitute for
the accurate rules. (Because they much more cheaply yield a useful
result or whatever.) We can stipulate an algorithm that is loaded with
precise heuristics. In this application area, heuristics can also have
the benefit of being easy to understand and their effect to predict.

An example of a heuristic rule in C is the difference between pp-numbers
tokens and actual numeric tokens. The preprocessing phases (originally
a separate program in the Unix implementation of C) uses a heuristic,
rather than the real rule, which brings about some simplifications as
well as benefits.

That old rule that an object cannot be modified more than once between
sequence points, and that an object shall be accessed only to determinet
he new value to be stored, is another example of a heuristic; the real
rule requires an elaborate formal model of sequence points.

Static checking itself is predicatid on heuristics. There are more
correct programs than programs that can be statically checked.
Sometimes, correct programs are diagnosed (and possibly rejected). For
instance, the rule that a conversion between pointers to unlike object
types requires a diagnostic is a heuristic, based on the inaccurate
estimate that many programs which requrest such conversions do so by
mistake, resulting in incorrectness. However, correct programs can exist
which do that, and so pointer casting is provided so those programs can
be made exceptions to the heuristic.

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

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

> Generally I tend to eschew conditional compilation[*]. [...]
> [*] With the occasional exception isolated to a header file.

All sensible people do. In almost all cases such platform
dependencies should be hidden and abstracted away well out
of sight (such as in a header) of the main code body.

On 2023-09-03, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On Sunday, 3 September 2023 at 08:15:28 UTC+1, Kaz Kylheku wrote:
>> If the app is free (the market rate for most apps), then a good
>> experience in that app that doesn't bring you $$$ isn't worth a
>> damn to the app's vendor.
>>
> Markets do sometimes throw up perverse incentives.
> But that's not why professional ergonmoics experts are employed, at
> least primarily.

OTOH, if some find themselves *unemployed*, that could be why. :)

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

> This discussion about minor points of design in C is interesting, but to me
> academic. This particular issue is:
>
> * A reluctance to write 'return x;' in a value-returning function

I don't remember anyone being reluctant to do that. I was reluctant to
do that in a function that was /not/ value returning (despite it having
a non-void return type), but even then it was a very specific case. I
have no reluctance to return a value from a function that should return
one and I will write, with no reluctance at all, an unneeded 'return x;'
to silence a warning when the situation comes up.

> * A desire for a compiler to turn a blind eye to that end, despite omitting
> such a return being bad news for 99% of functions

And no one has expressed that desire as far as I can recall. Everyone
is (so far as I recall) very happy to see the diagnostics about it.
Even you will be happy to see them when you start asking for them.

> * So leaving it pretty much a choice for the user whether they write it,
> and whether a compiler reports it.

That choice is indeed there. It's simply a fact. But no one here,
including you, seems prepared to do anything to change that fact. (I am
not including whinging about it in this tiny corner of the Internet as
"doing something about it". YMMV.)

> In C:
>
> void* fred(void) {
> (long long int)rand()*3.14159;
> }
>
> int main(void) {
> printf("%p\n", fred());
> printf("%p\n", fred());
> }
>
> The output varies considerably between 'bcc -old' and tcc/gcc. It is UB.
>
> So in C is it really not very hard, actually surprisingly easy; too easy:
> not a peep from the compiler invoked in what is likely the most common
> way.

I get at least three diagnostics about that program from gcc, but I
suspect you didn't post the actual program. But I get your point. It
is, as always, simply that you don't like gcc's defaults.

Since the gist of almost every complaint from you is that you don't want
to ask for diagnostics from gcc, it's worth saying why that is not such
a bad choice for the default. Running

gcc -o prog *.c

(or make!) is the sort of thing you do when you've got some code and
want to try it out. You are not a "developer" of the code, you just
want to run it. Any messages about the code are of no interest to you.
That situation calls for a lax approach to diagnostics, hence the
default.

No developer ever does that (unless they are not wearing their developer
hat at the time). They will at least run

gcc -Wall -o prog *.c

Can you promise that, from today, you won't complain about what gcc says
about some code unless you have at least asked for -Wall? There will
still be lots for you to moan about because that's only "warnings about
constructions that some users consider questionable, and that are easy
to avoid".

--
Ben.

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

> Ergonomics experts often design interfaces that I find hard to
> use. To take one example, I want to use common key binding across
> applications, but the experts seem to think there is only one such
> set (and it comes from an OS I have not used for years), so I
> can't use the bindings my fingers "know" about.

I'm curious to know more about the specifics here. What key
bindings, which "one set to rule them all", what domain of
applications followed that set? Also I'm curious to know how
you know (or why you suspect) the choices were made by experts?
What abilities or skills qualify them as experts?

> There are probably a few UI experts who really do know how to
> design easy to use, powerful interfaces that suit a wide rage of
> users with differing expectations and experience, but most of them
> just know how to make easy tasks easy for the most commonly
> encountered users.

I am not an expert, but I have three pieces of advice for anyone
who wants to design a good user interface.

1. Get a copy of TOG on interface, and read it. (And read it
again later.)

2. Follow Bill Atkinson's UI precepts:
* "The user has lost the manual"
* "... and didn't have time to read it before losing it"

3. Avoid anything that looks like a product from Microsoft, where
it seems like everyone thinks user interfaces should use the
same ideas and techniques as are used in video games.

On 03/09/2023 20:07, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:

>> In C:
>>
>> void* fred(void) {
>> (long long int)rand()*3.14159;
>> }
>>
>> int main(void) {
>> printf("%p\n", fred());
>> printf("%p\n", fred());
>> }
>>
>> The output varies considerably between 'bcc -old' and tcc/gcc. It is UB.
>>
>> So in C is it really not very hard, actually surprisingly easy; too easy:
>> not a peep from the compiler invoked in what is likely the most common
>> way.
>
> I get at least three diagnostics about that program from gcc, but I
> suspect you didn't post the actual program.

The program is shown below. The version posted was pasted from that, but
before I added the cast, which I added manually above.

--------------------------------
c:\c>type c.c
#include <stdio.h>
#include <stdlib.h>

void* fred(void) {
(long long int)rand()*3.14159;
}

int main(void) {
printf("%p\n", fred());
printf("%p\n", fred());
}

c:\c>gcc c.c

c:\c>a
0000000000000029
0000000000004823

c:\c>tcc c.c

c:\c>c
0000000000000029
0000000000004823

c:\c>bcc c.c -old
Compiling c.c to c.exe

c:\c>c
406019C41DD1A21E
40EC53F7C2CE4649

(Switching to WSL on the same folder:)

root@DESKTOP-11:/mnt/c/c# gcc c.c
root@DESKTOP-11:/mnt/c/c# ./a.out
0x6b8b4567
0x327b23c6

--------------------------------

If I use gcc -Wall (not -Wpedantic), I get a warning, but I still manage
to get an executable that I can run with potentially undesirable behaviour.

> But I get your point. It
> is, as always, simply that you don't like gcc's defaults.

As always, it always seems like I have to twist its arm to get it to do
its job. It's more complicated than simply using -Wall, since that gives
me warnings about things that are less serious, like unused labels.

> Since the gist of almost every complaint from you is that you don't want
> to ask for diagnostics from gcc, it's worth saying why that is not such
> a bad choice for the default. Running
>
> gcc -o prog *.c
>
> (or make!) is the sort of thing you do when you've got some code and
> want to try it out. You are not a "developer" of the code, you just
> want to run it. Any messages about the code are of no interest to you.
> That situation calls for a lax approach to diagnostics, hence the
> default.

This is open source situation that I have described, normally on a
working program. The problem is usually getting the information about
which files to submit as the /developer's/ build process is not suited.

> No developer ever does that (unless they are not wearing their developer
> hat at the time). They will at least run
>
> gcc -Wall -o prog *.c
>
> Can you promise that, from today, you won't complain about what gcc says
> about some code unless you have at least asked for -Wall? There will
> still be lots for you to moan about because that's only "warnings about
> constructions that some users consider questionable, and that are easy
> to avoid".

Let's take a slightly different version of my program, as before I
wanted to avoid a crash:

----------------------------
#include <stdio.h>
#include <stdlib.h>

char* fred(void) {
(long long int)rand()*3.14159;
}

int main(void) {
printf("%s\n", fred());
} ----------------------------

If I blindly do this, perhaps in a script:

c:\c>bcc c && c
Compiling c.c to c.exe
In function fred On line 5 in file c.c
**** ... Error: Function needs explicit return statement: fred ****

it won't let me run the program. If try it with gcc:

----------------------------
c:\c>gcc c.c -Wall && a
c.c: In function 'fred':
c.c:5:26: warning: value computed is not used [-Wunused-value]
5 | (long long int)rand()*3.14159;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
c.c:6:1: warning: control reaches end of non-void function [-Wreturn-type]
6 | }
| ^
----------------------------

it crashes. You can't see it here, but there's a small delay and a busy
cursor. So I'll try it on WSL:

----------------------------
root@DESKTOP-11:/mnt/c/c# gcc c.c -Wall && ./a.out
c.c: In function ‘fred’:
c.c:5:26: warning: value computed is not used [-Wunused-value]
5 | (long long int)rand()*3.14159;
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~
c.c:6:1: warning: control reaches end of non-void function [-Wreturn-type]
6 | }
| ^
Segmentation fault
----------------------------

So it's a little bit elaborate than just -Wall. Here is where I disagree
that I should go that rabbit-hole of myriad combinations of options in
order to get a supposed C compiler to do what I expect: detect obviously
wrong things in a program (NOT unused labels), and stop me running those.

I don't expect it to detect logic errors or prove my program is correct
or not. What I'm asking is quite possible in a simple compiler.

Do you know what the most common thing encountered with BCC is that
requires the -old option?

It is using a () parameter list for declarations rather than (void). ()
means the numbers and types of arguments to a function are completely
unchecked. Sounds really safe!

Mostly likely people wrongly assume that () means zero parameters. And
the reason for that is because a () parameter list is legal C; it just
doesn't mean what people think it means.

I decided that was too dangerous to allow by default. Now of course C23
decides it should means zero parameters too! This was why I said it was
going backwards.

Obviously what I'm after in a C compiler must be impossible:

* Compile code without needing any extra options most of the time

* (Ideally, not have to write .c on file names, but I can pass)

* Detect clearly wrong things and refuse to create an executable
that could have dangerously unsafe code.

* Make it obvious at the end (maybe I was out of the room when it
was working, and there was a lot of output) whether it passed or
failed.

David Brown <david.brown@hesbynett.no> writes:
>On 03/09/2023 17:54, Scott Lurndal wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 01/09/2023 20:59, Scott Lurndal wrote:
>>>> 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 )
>>>>
>>>
>>> Or even better, since this is a pragma in the source code, have it
>>> wrapped in conditional compilation that checks first for gcc, then for
>>> the gcc version. Sure, it can be a bit ugly, but it only needs to be
>>> written once and copied out verbatim by the code generator (or put in a
>>> common header file for the rest of us), and godbolt.org makes it very
>>> easy to test with different gcc versions.
>>>
>>
>> Generally I tend to eschew conditional compilation[*]. Not only is it
>> unattractive, it also significantly increases the verification burden
>> (multiplied by the number of predicates) and decreases significantly
>> the readability and maintainability of the code.
>>
>> I've seen code where every fourth line is #if. Completely
>> unreadable and very difficult to amend.
>>
>> [*] With the occasional exception isolated to a header file.
>
>I agree with your practice here. But one place where I think it does
>work well, is for such compiler-specific features. And yes, you put it
>all in a header file. In my business, it's not uncommon to see a header
>such as :
>
>// intrinsics.h
>#ifdef __GNUC__
>#include "gcc_intrinsics.h"
>#endif
>#ifdef __IAR__
>#include "iar_intrinsics.h"
>#endif
>
>etc.
>

Sure. That's the extent of it for me, generally.

#if defined(__GNUC__)

#define ALWAYS_INLINE inline __attribute__((always_inline))
#define barrier() asm volatile ("":::"memory")
#define CACHE_LINE_ALIGNED __attribute__((aligned(64)))
#define _x_CONSTRUCTOR __attribute__((constructor))
#define likely(x) __builtin_expect(!!(x), 1)
#define PACKED __attribute__((__packed__))
#define unlikely(x) __builtin_expect(!!(x), 0)

#else /* defined(__gnuc__) */

#define ALWAYS_INLINE
#define barrier()
#define CACHE_LINE_ALIGNED
#define _x_CONSTRUCTOR
#define likely(x) (x)
#define PACKED
#define unlikely(x) (x)

#define __attribute__(x)
#define __asm__(x)

#warning notgcc

#endif /* defined(__gnuc__) */

On 9/3/2023 2:25 PM, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 03/09/2023 17:54, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 01/09/2023 20:59, Scott Lurndal wrote:
>>>>> 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 )
>>>>>
>>>>
>>>> Or even better, since this is a pragma in the source code, have it
>>>> wrapped in conditional compilation that checks first for gcc, then for
>>>> the gcc version. Sure, it can be a bit ugly, but it only needs to be
>>>> written once and copied out verbatim by the code generator (or put in a
>>>> common header file for the rest of us), and godbolt.org makes it very
>>>> easy to test with different gcc versions.
>>>>
>>>
>>> Generally I tend to eschew conditional compilation[*]. Not only is it
>>> unattractive, it also significantly increases the verification burden
>>> (multiplied by the number of predicates) and decreases significantly
>>> the readability and maintainability of the code.
>>>
>>> I've seen code where every fourth line is #if. Completely
>>> unreadable and very difficult to amend.
>>>
>>> [*] With the occasional exception isolated to a header file.
>>
>> I agree with your practice here. But one place where I think it does
>> work well, is for such compiler-specific features. And yes, you put it
>> all in a header file. In my business, it's not uncommon to see a header
>> such as :
>>
>> // intrinsics.h
>> #ifdef __GNUC__
>> #include "gcc_intrinsics.h"
>> #endif
>> #ifdef __IAR__
>> #include "iar_intrinsics.h"
>> #endif
>>
>> etc.
>>
>
> Sure. That's the extent of it for me, generally.
>
> #if defined(__GNUC__)
>
> #define ALWAYS_INLINE inline __attribute__((always_inline))

> #define barrier() asm volatile ("":::"memory")

One little nit pick, barrier should probably be named compiler_barrier?
Ahhh, shit, this brings back memories when threads and atomics, membars
were not std.

> #define CACHE_LINE_ALIGNED __attribute__((aligned(64)))
> #define _x_CONSTRUCTOR __attribute__((constructor))
> #define likely(x) __builtin_expect(!!(x), 1)
> #define PACKED __attribute__((__packed__))
> #define unlikely(x) __builtin_expect(!!(x), 0)
>
> #else /* defined(__gnuc__) */
>
> #define ALWAYS_INLINE
> #define barrier()
> #define CACHE_LINE_ALIGNED
> #define _x_CONSTRUCTOR
> #define likely(x) (x)
> #define PACKED
> #define unlikely(x) (x)
>
>
> #define __attribute__(x)
> #define __asm__(x)
>
> #warning notgcc
>
> #endif /* defined(__gnuc__) */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> I wouldn't mind if a future edition of the C standard added a
> requirement that the } of a non-void function must be unreachable
> (with an exception for main()). There are languages that have such
> a requirement, and in my limited experience it works pretty well.
>
> The problem is that such a requirement requires the compiler
> to perform control flow analysis that's not otherwise required.
> Most large modern compilers already do such analysis for optimization
> and diagnostic purposes; at most they might have to enable it
> at all optimization levels. Small "hobby" compilers might have
> to do some extra work -- but such compilers often aren't fully
> conforming anyway.
>
> Such a requirement would have been a more substantial burden when
> the language was originally being defined, and inertia probably
> has a lot to do with why it hasn't been imposed since then.
>
> I think we'd need a rigorous definition of reachability that's not too
> difficult to implement. It might require adding unnecessary return
> statements in some corner cases, but IMHO that's ok. There's precedent
> in other languages that C could steal.

I found a concrete example: C#.

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/statements#132-end-points-and-reachability

If a statement can possibly be reached by execution, the statement
is said to be reachable. Conversely, if there is no possibility that
a statement will be executed, the statement is said to be
*unreachable*.
...
Note: To determine whether a particular statement or end point is
reachable, the compiler performs flow analysis according to the
reachability rules defined for each statement. The flow analysis
takes into account the values of constant expressions (§12.23) that
control the behavior of statements, but the possible values of
non-constant expressions are not considered. In other words, for
purposes of control flow analysis, a non-constant expression of a
given type is considered to have any possible value of that type.
...
It is a compile-time error for the end point of the block of a
function member or an anonymous function that computes a value to be
reachable. If this error occurs, it typically is an indication that
a return statement is missing (§13.10.5).

*If* a future C standard were to introduce new rules like we've been
discussing, I suggest that adapting the current C# rules could be a good
approach.

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

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

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Ergonomics experts often design interfaces that I find hard to
>> use. To take one example, I want to use common key binding across
>> applications, but the experts seem to think there is only one such
>> set (and it comes from an OS I have not used for years), so I
>> can't use the bindings my fingers "know" about.
>
> I'm curious to know more about the specifics here. What key
> bindings, which "one set to rule them all", what domain of
> applications followed that set?

I like to use Emacs keybindings. I can use them in bash and programs
that use GNU readline which includes a lot of REPL programs like ghci,
swipl, gp and so on. I can't use them in the Gnome browser.

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

> Also I'm curious to know how
> you know (or why you suspect) the choices were made by experts?

I don't. Maybe I should have put "experts" it scare quotes. I stated
to notice the loss of configuration when Gnome got a team in to clean up
the interface and develop a set of rules to simplify things for the
average user. They may not have been experts, but the announcement
suggested they were.

> What abilities or skills qualify them as experts?

Too big a topic. I hope you won't mind if I just don't even try to
answer that.

--
Ben.

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-09-03, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>> [...]
>>
>>> I wouldn't mind if a future edition of the C standard added a
>>> requirement that the } of a non-void function must be unreachable
>>> (with an exception for main()). There are languages that have such
>>> a requirement, and in my limited experience it works pretty well.
>>>
>>> The problem is that such a requirement requires the compiler
>>> to perform control flow analysis that's not otherwise required.
>>> [...]
>>
>> The problem is that in C such a determination cannot be made
>> precisely, for reasons that are both theoretical and practical.
>> Only heuristics are possible, but requirements in the C standard
>> are never stated in terms of heuristics (and rightly so).
>
> I believe this is false on both counts.
>
> There is nothing imprecise about "heuristics". What heuristics
> aren't is "accurate". [...]

Stop quibbling. The point is that any proposed rule will
sometimes give wrong answers, because there is no way for
any computable function to give correct assessments in all
cases.

On Sunday, 3 September 2023 at 16:24:50 UTC+1, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> > On Saturday, 2 September 2023 at 23:28:30 UTC+1, Ben Bacarisse wrote:
> >> Malcolm McLean <malcolm.ar...@gmail.com> writes:
>
> Ergonomics experts often design interfaces that I find hard to use. To
> take one example, I want to use common key binding across applications,
> but the experts seem to think there is only one such set (and it comes
> from an OS I have not used for years), so I can't use the bindings my
> fingers "know" about.
>
> There are probably a few UI experts who really do know how to design
> easy to use, powerful interfaces that suit a wide rage of users with
> differing expectations and experience, but most of them just know how to
> make easy tasks easy for the most commonly encountered users.
>
It's a new discipline, so some basic mistakes are still made. For instance
Microsoft released Windows 8, which had a mobile-phone style interface.
Completely unsuitable and unusable for a personal computer. It was
swiftly withdraw. But that such a large company could have made such a
blunder with its central product tells you how immature the field really is.

One problem is that, with many software packages, a few routine and basic
tasks are easy, and can be done without training. But anything more complicated
is very difficult. We spend a fortune making documents and training videos
for our products, and we still haven't got it right.
>
> > No-one is going to deny that interfaces should suit the target users. But
> > whilst true, it's not helpful. "Programmers shouldn't design interfaces"
> > is more controversial (often they do, often there is no choice because unlike
> > Microsoft, you are to small to have a "usability lab" all products have to
> > go through) . So that makes it worth saying.
> But it says very little because "programmers" are not a uniform group.
> For example, the HCI research team I used to work alongside was almost
> entirely made up of people who could be described as programmers. Sure,
> they were also psychologists, linguists and graphic designers, but they
> all had top-notch programming skills as well.
>
A programmer can also wear another hat, that's true.
>
> > So, reluctantly, I agree that I can't have what I want. So we'll need
> > an option. Debug mode and release mode, maybe more.
> I see. Now I know what you were getting at: options are sometimes a
> consequence of impossible specifications. That's not an interesting
> observation (to me) but it certainly does not constitute a general rule
> about programs.
>
As it happens the natural specification of a compiler - take in a file in the
source language and produce the best program which does the same
thing in the target language - is one which cannot be achieved for theoretical
as well as practical reasons.
But that's not essential to my point. It also applies to specifications which are
possible but difficult to achieve. And to poor design decisions which may not
be under the control of the program, for example it is impossible to distinguish
big-endian from little endian UTF-16 without a byte order mark, so it's necessary
to provide an option to the user if you are to support every possible input.
Of course a well designed program will use a heuristic, but it's not that easy to
design, and lazy implementers will just rely on the option.

Bart <bc@freeuk.com> writes:

> On 03/09/2023 20:07, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> In C:
>>>
>>> void* fred(void) {
>>> (long long int)rand()*3.14159;
>>> }
>>>
>>> int main(void) {
>>> printf("%p\n", fred());
>>> printf("%p\n", fred());
>>> }
>>>
>>> The output varies considerably between 'bcc -old' and tcc/gcc. It is UB.
>>>
>>> So in C is it really not very hard, actually surprisingly easy; too easy:
>>> not a peep from the compiler invoked in what is likely the most common
>>> way.
>> I get at least three diagnostics about that program from gcc, but I
>> suspect you didn't post the actual program.
>
> The program is shown below.

Yes, I know what you intended to post.

> If I use gcc -Wall (not -Wpedantic), I get a warning, but I still manage to
> get an executable that I can run with potentially undesirable
> behaviour.

Some people advise compiling with -Werror. I advice you to either set
specific ones (-Werror=xyz) or set them all and down-grade those you
don't care so much about (-Werror -Wno-error=xyz).

>> But I get your point. It
>> is, as always, simply that you don't like gcc's defaults.
>
> As always, it always seems like I have to twist its arm to get it to do its
> job. It's more complicated than simply using -Wall, since that gives me
> warnings about things that are less serious, like unused labels.

How often will go round this same loop? You don't like gcc's defaults.
I know that, you know that. You also know how to change them. By this
stage, if you wanted to use gcc, you could have set it up to match,
pretty closely, your requirements. If you don't want to use gcc, don't
use it and stop complaining about its defaults.

You can't make the world a better place by moaning. You can help by
replying to posts by beginners, helping them to understand the pitfalls
of C and telling them how to get more help from compilers like gcc. You
could even try to persuade them to use an alternative language, but
moaning won't do anything.

>> Since the gist of almost every complaint from you is that you don't want
>> to ask for diagnostics from gcc, it's worth saying why that is not such
>> a bad choice for the default. Running
>> gcc -o prog *.c
>> (or make!) is the sort of thing you do when you've got some code and
>> want to try it out. You are not a "developer" of the code, you just
>> want to run it. Any messages about the code are of no interest to you.
>> That situation calls for a lax approach to diagnostics, hence the
>> default.
>
> This is open source situation that I have described, normally on a working
> program. The problem is usually getting the information about which files
> to submit as the /developer's/ build process is not suited.

Yes, your second most common moan is that developers have not ported
their build system to your preferred OS, but you won't help by setting
something up for them for even a single program (not all of them, just
on you care about!). (You have falsely claimed that when I suggest this
I'm asking you to work on every program out there.)

>> No developer ever does that (unless they are not wearing their developer
>> hat at the time). They will at least run
>> gcc -Wall -o prog *.c
>> Can you promise that, from today, you won't complain about what gcc says
>> about some code unless you have at least asked for -Wall?

No answer I see.

>> There will
>> still be lots for you to moan about because that's only "warnings about
>> constructions that some users consider questionable, and that are easy
>> to avoid".
>
> Let's take a slightly different version of my program, as before I wanted
> to avoid a crash:

I see no point, since you present nothing new. You don't like gcc's
defaults (in this extended moan, you don't like that an executable is
still built after a warning). Set gcc up to be what you want or stop
complaining about it.

> Here is where I disagree
> that I should go that rabbit-hole of myriad combinations of options in
> order to get a supposed C compiler to do what I expect: detect obviously
> wrong things in a program (NOT unused labels), and stop me running
> those.

Don't use gcc then. You are missing out on a very useful tool, though,
as it can also detect run-time issues with options like
-fsanitize=undefined. I would have given my right arm for a tool like
gcc when I was a working C programmer back in the last century.

> Obviously what I'm after in a C compiler must be impossible:
>
> * Compile code without needing any extra options most of the time

To be frank, that's just a silly thing to say. If I write (in my bash
set-up)

function bencc {
gcc -std=c99 -pedantic -Wall -Werror "$@"
}

then I have new C compiler called bencc that does a different job than
the gcc command.

You should have done this years ago and refined the options (probably
via a file) as you found things that you prefer to be done this way or
that way. It's trivial. Do it now.

> * (Ideally, not have to write .c on file names, but I can pass)
>
> * Detect clearly wrong things and refuse to create an executable
> that could have dangerously unsafe code.

Use bencc.

> * Make it obvious at the end (maybe I was out of the room when it
> was working, and there was a lot of output) whether it passed or
> failed.

function cc { bencc "$@" && echo OK || echo FAILED; }

--
Ben.

Bart <bc@freeuk.com> writes:

> On 03/09/2023 15:31, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> Take this program:
>>>
>>> void fred(void){}; void bill(void)
>> This program has two syntax errors.
>
> Sorry, I found that when I tested the above but forgot to update the post.
>
>> The one you are talking about and
>> the missing ; or missing compound statement as the end of the line.
>>
>>> There's an extraneous ";" that the grammar says shouldn't be there, so it's
>>> a syntax error.
>>>
>>> Should a compiler fail it or not?
>> The standard says that it should be reported.
>
> And yet the first four compilers I tried don't do that.

Most programs that claim to be C compilers are not C compilers. For
example, nether the gcc nor clang command (run just like that) is a C
compiler. Both can be turned into one by simply providing a couple of
flags. I suspect, because you know this perfectly well, that you
deliberately did not run the program though a C compiler but through a
C-plus-some-set-of-extensions compiler.

Of course, compilers also have bugs. If you found an actual C compiler
that does not spot that error, then I hope you reported the bug.

>>> Most compilers say nothing, or at best can be coaxed into a warning.
>> More rhetorical spin. For gcc and clang (to take tho I can easily test)
>> if you ask them to check for standard C syntax,
>
> Clearly, many people don't do so. Or if they do, they ignore the
> warnings.

Most people who want to have C's rules applied, rather than some other
related set of rules, will learn how to do that. You appear to be an
exception. You want to know what C does or does not require (mainly so
you can complain about it) but you refuse to run a C compiler.

>> they both tell you the ;
>> should not be there.
>
> But, they will still produce an executable. Not much of an incentive is it?
>
> Both, by default, implement a whole bunch of
>> extensions. It's not "coaxing" to tell a tool to do what you want.
>
> The upshot is that there will still be codebases that may contain that
> extra ";", which can bite later when compiled more strictly.
>
> With my suggestion to fix it at an early stage, no codebase created using
> that approach will have the extra semicolon.

I think such errors should be fixed. You, of all people, should run
code through a C compiler and not a C-plus-extensions compiler.

--
Ben.

On 03/09/2023 19:11, Bart wrote:
> On 03/09/2023 15:02, David Brown wrote:
>> On 02/09/2023 20:53, Bart wrote:
>
>>> What exactly are the consequences of requiring programs to satisfy my
>>> compiler regarding 'return'? Virtually one. But it would then be
>>> impossible to write a function without a proper return value.
>>>
>>
>> You live in such a small bubble!  Don't you ever feel the need to look
>> outside, or at least /think/ a bit about the rest of the world?
>
>
> 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.

>
> Anyway, my view is that it is you who live in more of a bubble, even if
> a very large and complex one! I at least can look outside C at my
> languages which are of the same rank, and compare how they approach
> common problems.

I think you'll find that most people here - and certainly all of the
regulars - have a lot of experience with a variety of programming
languages. Probably a fair fraction do not use C much in their regular
programming. We focus on C here, because it is a C discussion group.
Do not imagine for a moment that you are special because you have
another language to compare to C.

> I acknowledge that it is easy for me to try new things, but that itself
> allows me to say whether they are better than how C does it, or worse.
> (Usually the former! The others don't last long.)

No, it does not allow you to say anything of the sort - except within
the very limited and niche confines of your little bubble. You have no
concept of how your ideas might work or fail to work in the real world -
you've demonstrated that repeatedly here. You have no inkling about
what other people want or need, or how they could apply to other
people's projects. This is because you directly avoid anything outside
your bubble, refuse to listen to anything people tell you, and you will
not make any attempt to learn or understand. Nothing gets through your
walls of smugness, self-satisfaction, and irrational hatred.

That does not mean you don't have good ideas, or that your programming
languages don't have their good points - far from it, there are some
nice things there. They are not as unique or innovative as you believe,
and certainly not as universally good, but can be good things for at
least some people and some uses.

>
> You can't that because there is nothing to compare with except languages
> at a very different level.
>

What an odd and ignorant thing to say.

On 04/09/2023 03:17, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 03/09/2023 15:31, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> Take this program:
>>>>
>>>> void fred(void){}; void bill(void)
>>> This program has two syntax errors.
>>
>> Sorry, I found that when I tested the above but forgot to update the post.
>>
>>> The one you are talking about and
>>> the missing ; or missing compound statement as the end of the line.
>>>
>>>> There's an extraneous ";" that the grammar says shouldn't be there, so it's
>>>> a syntax error.
>>>>
>>>> Should a compiler fail it or not?
>>> The standard says that it should be reported.
>>
>> And yet the first four compilers I tried don't do that.
>
> Most programs that claim to be C compilers are not C compilers. For
> example, nether the gcc nor clang command (run just like that) is a C
> compiler.

Ha ha ha!

And here /you/ go around the same loop!

Oh, you know the product that we've been hailing as the flagship C
compiler for that few thousand posts, well it isn't really a C compiler
anyway!

So what exactly is a C compiler? What does it do? Don't bother answering.

Next I fully expect you will say that C isn't really a language. From
what I've gleaned here, it isn't. It's a collection of suggestions and
recommendations as to how an input file might be processed.

There's so much gaslighting going on here that I'm almost starting to
question my own ideas.

/My/ idea of a compiler is a simple box, with a single Go button. You
feed in a tape at one side representing source code and it writes a tape
on the other with a runnable program. When it's finished a green light
flashes. The output tape I can subsequently feed into a computer to execute.

If there's a problem with the input, a red light flashes, and no output
tape is produced.

It's almost like a consumer product that anyone can use.

Now, what would gcc look like when expressed like that? How many
thousands of buttons and lights would it have? What actual language
would be accepted? How many colours of errors lights would there be? I
know there is no green light.

How big would it be? Would it be one huge box, or would be contain other
boxes? How many different languages could it deal with?

One more thing about this box: if you don't set the dials for the title
of the output take, it will overwrite the same tape it producted a
minute ago! And of course the buttons, switches and dials all reset
themselves each time.

If we turn our attention to the question of building a program
comprising many input tapes, I would use pretty much the same simple
box. You would use another giant box with yet another 1000 buttons
called 'make', and perhaps even more boxes.

So excuse me for trying to tidy up the notions of 'language' and
'compiler' into small, simple, consumer-like concepts and tools.

I don't know what I was thinking.

> Both can be turned into one by simply providing a couple of
> flags.

Sure, prepare a special tape containing the preferred settings for those
thousands of switches. And somebody else can feed in their own tape, so
that same program tape P produces a different result.

Now if you want someone else to be able to produce the same output tape,
they will need:

* The same language tape of course

* Your extra settings tape

* The exact same make, model and version of box

Remember my remark about your program not being defined purely by the C
source code?

> Most people who want to have C's rules applied, rather than some other
> related set of rules, will learn how to do that. You appear to be an
> exception. You want to know what C does or does not require (mainly so
> you can complain about it) but you refuse to run a C compiler.

Who's to say what a C compiler is? You seem unwilling to accept my idea
of it which is outlined above. But we have to accept yours?

>>> they both tell you the ;
>>> should not be there.
>>
>> But, they will still produce an executable. Not much of an incentive is it?
>>
>> Both, by default, implement a whole bunch of
>>> extensions. It's not "coaxing" to tell a tool to do what you want.
>>
>> The upshot is that there will still be codebases that may contain that
>> extra ";", which can bite later when compiled more strictly.
>>
>> With my suggestion to fix it at an early stage, no codebase created using
>> that approach will have the extra semicolon.
>
> I think such errors should be fixed. You, of all people, should run
> code through a C compiler and not a C-plus-extensions compiler.

So, what is a C compiler again? Why can't I can't just download a 'C
compiler' and run it, why does everyone have to create their own custom
compilers for a language which ought to be the same for everyone?

That is, a language designated as C90, C99, C11 or C23. C23 is new, but
can somebody actually download a C11 compiler and have it compile strict
C11 code without first having to set up a 'C11' program on all those
switches?

Will that 'C11' compiler fail my crashing program?

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. A good idea is
a good idea.

>
>

> We focus on C here, because it is a C discussion group.

The thread has been largely about how compilers work. That surely can be
compared with how compilers for like languages work. Or even how my
compiler for C works.

> Do
> not imagine for a moment that you are special because you have another
> language to compare to C.

Why not? How many here:

* Have used a viable alternative to C for most of their careers?
(I don't mean C++!)

* How many have /designed and implemented/ that alternative?

* How many here have written compilers? That includes a 'full stack'
implementation

* How many here have tried implementing a C compiler?

You don't think that can give someone a rather special perspective?

You can tell any other upstart, This is what a C compiler is and how it
is supposed to work. But not when that upstart says, No, a C compiler
can also look and behave like /this/, because I've done it.

>> I acknowledge that it is easy for me to try new things, but that
>> itself allows me to say whether they are better than how C does it, or
>> worse. (Usually the former! The others don't last long.)
>
> No, it does not allow you to say anything of the sort - except within
> the very limited and niche confines of your little bubble.  You have no
> concept of how your ideas might work or fail to work in the real world -
> you've demonstrated that repeatedly here.

The real world consisting of half a century's accumulation of cruft in
the C language, compilers, options, libraries, makefiles and assorted
other tools?

I fully agree.

Of course, you can /change/ that in the real world if somebody put their
mind to it. But nobody will. Most people's contribution in that area is
to add to the cruft: 51 year's accummulatation instead of 50!

>  You have no inkling about
> what other people want or need, or how they could apply to other
> people's projects.  This is because you directly avoid anything outside
> your bubble, refuse to listen to anything people tell you, and you will
> not make any attempt to learn or understand.  Nothing gets through your
> walls of smugness, self-satisfaction, and irrational hatred.
>
> That does not mean you don't have good ideas, or that your programming
> languages don't have their good points - far from it, there are some
> nice things there.  They are not as unique or innovative as you believe,
> and certainly not as universally good, but can be good things for at
> least some people and some uses.

And yet, I can't get this program to compile when expressed in my langage:

char* fred(void) {
(long long int)rand()*3.14159;
}

int main(void) {
printf("%s\n", fred());
}

I can very easily do so in C, /and/ I can run it.

And not by providing extra options to override compiler's choices; you
don't have to provide /any/ options!

I don't really need to say anything else.

>
>>
>> You can't that because there is nothing to compare with except
>> languages at a very different level.
>>

> What an odd and ignorant thing to say.

Why is it odd? You can't compare the handling of a feature between C and
Python, or C and Haskell, because they are too different. You /can/
compare between C and my language, because even you said (in
comp.lang.misc) that they were more or less the same language. Just very
different implementations.