Em 2/10/2024 6:49 PM, Kaz Kylheku escreveu:
> On 2024-02-10, bart <bc@freeuk.com> wrote:
>> #include <stdio.h>
>> int main(void) {
>> int a;
>> L1:
>> printf("Hello, World!\n");
>> }
>>
>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>> 'L1'. Use -Werror and the compilation will fail.
>>
>> Is there anyone here who thinks that running this program with those
>> unused identifiers is not completely harmless?
>
> Unused warnings exist because they help catch bugs.
>
> double distance(double x, double y)
> {
> return sqrt(x*x + x*x);
> }

Unused warning is a good sample to explain my point of view.
I want a "warning profile" inside the compiler to do a "automatic code
review".
The criteria is not only complain about UB etc..the criteria is the same
used by humans (in the context of the program, how critical etc) to
approve or not a code.

Unused is a good sample, a human reviewing your code would ask why
something is not used for instance.

In code review I also try to make a code review that does not depend on
the review of the caller.

for instance

void f(int a[])
{ a[1]= 1;
}

this code depends review of the caller.

We can create alternatives that will check input.

void f(int n, int a[n])
{

}
I wish a warning profile to catch this type of "caller" dependent function.
The other common sample is null pointers, where the function assumes the
caller will not pass a null pointer.

I want to have a classification for that - a "name" - to classify
function with "caller contract dependent" something like that.

One way I am thinking to create a warning profile is a set of warnings I
want as as error etc..
then the user can configure the compiler according with the company
guidelines.

The idea of making warnings part of the C standard helps to make "safety
portable" then the program can have the same guarantees independent of
the tool used.

On 10/02/2024 21:49, Kaz Kylheku wrote:
> On 2024-02-10, bart <bc@freeuk.com> wrote:
>> #include <stdio.h>
>> int main(void) {
>> int a;
>> L1:
>> printf("Hello, World!\n");
>> }
>>
>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>> 'L1'. Use -Werror and the compilation will fail.
>>
>> Is there anyone here who thinks that running this program with those
>> unused identifiers is not completely harmless?
>
> Unused warnings exist because they help catch bugs.
>
> double distance(double x, double y)
> {
> return sqrt(x*x + x*x);
> }
>
> The diagnostic will not catch all bugs of this type, since just one use is
> enough to silence it, but catching something is better than nothing.

> Removing unused cruft also helps to keep the code clean. Stray material
> sometimes gets left behind after refactoring, or careless copy paste.
> Unused identifiers are a "code smell".

This is a different kind of analysis. IMV it doesn't belong in a routine
compilation, just something you do periodically, or when you're stuck
for ideas.

In your example, maybe you did want x*x*2, and the 'y' is either a
parameter no longer needed, or not yet needed, or temporarily not used.

So it is not 'obviously wrong', and by itself, not using a parameter is
harmless.

I'm looking for a result from a compiler which is either Pass or Fail,
not Maybe.

> Sometimes something must be left unused. It's good to be explicit about
> that: to have some indication that it's deliberately unused.
>
> When I implemented unused warnings in my Lisp compiler, I found a bug right away.
>
> https://www.kylheku.com/cgit/txr/commit/?id=5ee2cd3b2304287c010237e03be4d181412e066f
>
> In this diff hunk against in the assembler:
>
> @@ -217,9 +218,9 @@
> (q me.(cur-pos)))
> (inc c)
> me.(set-pos p)
> - (format t "~,5d: ~,08X ~a\n" (trunc p 4) me.(get-word) dis-txt)
> + (format stream "~,5d: ~,08X ~a\n" (trunc p 4) me.(get-word) dis-txt)
> (while (< (inc p 4) q)
> - (format t "~,5d: ~,08X\n" (trunc p 4) me.(get-word)))
> + (format stream "~,5d: ~,08X\n" (trunc p 4) me.(get-word)))
> me.(set-pos q)
> (set p q)))
> c))
>
> The format function was given argument t, a nickname for standard output, so
> this code ignored the stream parameter and always sent output to standard
> output.
>
> With the unused warnings, it got diagnosed.

So you use the linty options when you're stuck with a bug, as I suggested.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[snip discussion of a program that divides by zero]

> An implementation can refuse to translate the program, but not
> because undefined behavior occurs. The undefined behavior here
> happens only when the program is executed, but just compiling the
> program doesn't do that. No execution, no undefined behavior.
> Still the program may be rejected, because it is not strictly
> conforming (by virtue of having output depend on the undefined
> behavior if the program is ever run).

Just to be clear, would you say that a conforming hosted implementation
may reject this program:

#include <limits.h>
#include <stdio.h>
int main(void) {
printf("INT_MAX = %d\n", INT_MAX);
}

solely because it's not strictly conforming?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

bart <bc@freeuk.com> writes:
> On 10/02/2024 01:59, Tim Rentsch wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>
>>> This is something which has long been of fascination to me: how
>>> exactly do you get a C compiler to actually fail a program with a
>>> hard error when there is obviously something wrong, while not also
>>> failing on completely harmless matters.

The only thing that *requires* a compiler to reject a translation unit
is the #error directive. For any violation of a syntax rule or
constraint, the standard only requires a *diagnostic message*, which can
be a non-fatal warning.

Most C compilers reject translation units for other reasons, and most
have options to control those reasons.

>> I think the answer is obvious: unless and until you find someone
>> who works on a C compiler and who has exactly the same sense that
>> you do of "when there is obviously something wrong" and of what
>> conditions fall under the heading of "completely harmless matters",
>> and also the same sense that you do of how a C compiler should
>> behave in those cases, you won't get exactly what you want unless
>> you do it yourself.
>
>
> Take this function:
>
> void F() {
> F();
> F(1);
> F(1, 2.0);
> F(1, 2.0, "3");
> F(1, 2.0, "3", F);
> }
>
> Even if /one/ of those calls is correct, the other four can't be
> possibly be correct as well.

True, if by "correct" you mean "avoids undefined behavior". In fact
only the first call is correct (and since it's endlessly recursive, it
prevents any of the others from being executed, something that a
compiler may or may not notice).

No syntax error or constraint is violated (prior to C23), so no
diagnostic is required.

> Is there anyone here who doesn't think there is something obviously wrong?

Something is wrong, and is easily avoided by not using old-style
function declarations and definitions, which have been obsolescent since
1989.

> How about this one:
>
> #include <stdio.h>
> int main(void) {
> int a;
> L1:
> printf("Hello, World!\n");
> }
>
> Ramp up the warnings and a compiler will tell you about unused 'a' and
> 'L1'. Use -Werror and the compilation will fail.

Use -Werror and the compiler is non-conforming, since it will reject a
translation unit for anything that the authors thought was worth warning
about. Nevertheless, the -Werror option (or equivalent) can be useful.

> Is there anyone here who thinks that running this program with those
> unused identifiers is not completely harmless?

Is there anyone here who thinks that a compiler can be clever enough to
be trusted to determine whether an unused identifier is harmless or not?
If you have an unused identifier, it's likely you've written something
other than what you meant. A compiler can't know what you meant.

There are very good reasons for warning about unused identifiers.
They are very likely to be symptoms of bugs. If you don't want those
particular warnings, there are likely to be ways to disable them.
Aside from command-line arguments, `(void)a;` is likely to inhibit
the warning. As for an unused label, you can delete it or comment
it out.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Sat, 10 Feb 2024 20:22:52 +0000, bart <bc@freeuk.com> wrote in
<uq8lus$3dceu$1@dont-email.me>:

> How about this one:
>
> #include <stdio.h>
> int main(void) {
> int a;
> L1:
> printf("Hello, World!\n");
> }
>
> Ramp up the warnings and a compiler will tell you about unused 'a' and
> 'L1'. Use -Werror and the compilation will fail.
>
> Is there anyone here who thinks that running this program with those
> unused identifiers is not completely harmless?

Yet you promoted warnings to errors, just to find a way to make
it fail. :(

("Is there anyone here who thinks that" bart's continuous
complaining about options to gcc deserve any merit?)

Regarding the topic, I'm curious why there is resistance
to conditionals written like this:

if( 1 == a)

...that is to say, with the constant first.

I've done that in C and Perl. Are the aesthetics so
bad that I should quit that? Isn't it safer to write
it that way, so that a dropped "=" is pointed out on
compilation?

--
-v

On 11/02/2024 00:40, vallor wrote:
> On Sat, 10 Feb 2024 20:22:52 +0000, bart <bc@freeuk.com> wrote in
> <uq8lus$3dceu$1@dont-email.me>:
>
>> How about this one:
>>
>> #include <stdio.h>
>> int main(void) {
>> int a;
>> L1:
>> printf("Hello, World!\n");
>> }
>>
>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>> 'L1'. Use -Werror and the compilation will fail.
>>
>> Is there anyone here who thinks that running this program with those
>> unused identifiers is not completely harmless?
>
> Yet you promoted warnings to errors, just to find a way to make
> it fail. :(

I didn't promote anything. I said IF you increased the warnings, AND
used -Werror, it will fail.

-Werror is what has always been suggested to me when I complain that
some clear error only results in a warning, which means a runnable
program has been produced.

>
> ("Is there anyone here who thinks that" bart's continuous
> complaining about options to gcc deserve any merit?)

Actually I didn't mention gcc. But when I do, if it managed to do its
job without so much effort on my part then there would be fewer complaints.

bart <bc@freeuk.com> writes:
[...]
> So it is not 'obviously wrong', and by itself, not using a parameter
> is harmless.
>
> I'm looking for a result from a compiler which is either Pass or Fail,
> not Maybe.
[...]

So you don't like compiler warnings about things that are not clearly
wrong.

That's a valid preference, but it's not one that's shared by most
programmers or supported by most compilers.

I suppose one way to get what you want is to use "gcc -pedantic-errors"
and ignore all warnings, (or do the equivalent for whatever compiler
you're using. Or there may be a way to turn off all warnings that
don't indicate violations of constraints or syntax rules, but since
that's not the behavior I want I haven't taken the time to investigate.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

vallor <vallor@cultnix.org> writes:
[...]
> Regarding the topic, I'm curious why there is resistance
> to conditionals written like this:
>
> if( 1 == a)
>
> ...that is to say, with the constant first.
>
> I've done that in C and Perl. Are the aesthetics so
> bad that I should quit that? Isn't it safer to write
> it that way, so that a dropped "=" is pointed out on
> compilation?

I personally find "Yoda conditions" jarring.

I'm aware that `1 == a` and `a == 1` are equivalent, but I read them
differently. The latter asks something about a, namely whether it's
equal to 1. The former asks something about 1, which is inevitably a
silly question; I already know all about 1. I find that when reading
such code, I have to pause for a moment (perhaps a fraction of a second)
and mentally reverse the condition to understand it.

Note that I'm describing, not defending, the way I react to it.

Writing "=" rather than "==" is a sufficienly rare mistake, and likely
to be caught quickly because most compilers warn about it, that it's
just not worth scrambling the code to avoid it.

If you've internalized the commutativity of "==" so well that seeing
`1 == a` rather than `a == 1` doesn't bother you, that's fine.
But consider that some people reading your code are likely to have
reactions similar to mine.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-02-11, bart <bc@freeuk.com> wrote:
> On 10/02/2024 21:49, Kaz Kylheku wrote:
>> On 2024-02-10, bart <bc@freeuk.com> wrote:
>>> #include <stdio.h>
>>> int main(void) {
>>> int a;
>>> L1:
>>> printf("Hello, World!\n");
>>> }
>>>
>>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>>> 'L1'. Use -Werror and the compilation will fail.
>>>
>>> Is there anyone here who thinks that running this program with those
>>> unused identifiers is not completely harmless?
>>
>> Unused warnings exist because they help catch bugs.
>>
>> double distance(double x, double y)
>> {
>> return sqrt(x*x + x*x);
>> }
>>
>> The diagnostic will not catch all bugs of this type, since just one use is
>> enough to silence it, but catching something is better than nothing.
>
>> Removing unused cruft also helps to keep the code clean. Stray material
>> sometimes gets left behind after refactoring, or careless copy paste.
>> Unused identifiers are a "code smell".
>
> This is a different kind of analysis. IMV it doesn't belong in a routine
> compilation, just something you do periodically, or when you're stuck
> for ideas.

Periodically translates to never. If there are some situations you don't
want in the code, the best thing is to intercept any change which
introduces such, and not allow it to be merged.

> In your example, maybe you did want x*x*2, and the 'y' is either a
> parameter no longer needed, or not yet needed, or temporarily not used.

If we take a correct program and add an unused variable to it, it
doesn't break. Everyone knows that. That isn't the point.

> So it is not 'obviously wrong', and by itself, not using a parameter is
> harmless.

While it's not obviously wrong, it's not obviously right either.

Moreover, it is a hard fact that the parameter y is not used.

Granted, not every truth about a program is equally useful, but
experience shows that reporting unused identifiers pays off. My own
experience and experiences of others. That's why such diagnostics are
implemented in compilers.

> I'm looking for a result from a compiler which is either Pass or Fail,
> not Maybe.

Things are fortunately not going to revert to the 1982 state of the
art, though.

The job of the compile is not only to translate the code or report
failure, but to unearth noteworthy facts about the code and remark on
them.

>> With the unused warnings, it got diagnosed.
>
> So you use the linty options when you're stuck with a bug, as I suggested.

The point is, I would likely not have found that bug to this day without
the diagnostic. You want to be informed /before/ the bug is identified
in the field.

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

vallor <vallor@cultnix.org> writes:

> [...] I'm curious why there is resistance to conditionals written
> like this:
>
> if( 1 == a)
>
> ...that is to say, with the constant first.
>
> I've done that in C and Perl. Are the aesthetics so
> bad that I should quit that? Isn't it safer to write
> it that way, so that a dropped "=" is pointed out on
> compilation?

Do you know the phrase too clever by half? It describes
this coding practice. A partial solution at best, and
what's worse it comes with a cost for both writers and
readers of the code. It's easier and more effective just
to use -Wparentheses, which doesn't muck up the code and
can be turned on and off easily. There are better ways
for developers to spend their time than trying to take
advantage of clever but tricky schemes that don't help
very much and are done more thoroughly and more reliably
by using pre-existing automated tools. Too much buck,
not nearly enough bang.

bart <bc@freeuk.com> writes:

> On 10/02/2024 01:59, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>> [...]
>>
>>> This is something which has long been of fascination to me: how
>>> exactly do you get a C compiler to actually fail a program with a
>>> hard error when there is obviously something wrong, while not also
>>> failing on completely harmless matters.
>>
>> I think the answer is obvious: unless and until you find someone
>> who works on a C compiler and who has exactly the same sense that
>> you do of "when there is obviously something wrong" and of what
>> conditions fall under the heading of "completely harmless matters",
>> and also the same sense that you do of how a C compiler should
>> behave in those cases, you won't get exactly what you want unless
>> you do it yourself.
>
> Take this function:
>
> void F() {
> F();
> F(1);
> F(1, 2.0);
> F(1, 2.0, "3");
> F(1, 2.0, "3", F);
> }
>
> Even if /one/ of those calls is correct, the other four can't be
> possibly be correct as well.
>
> Is there anyone here who doesn't think there is something obviously wrong?
>
> How about this one:
>
> #include <stdio.h>
> int main(void) {
> int a;
> L1:
> printf("Hello, World!\n");
> }
>
> Ramp up the warnings and a compiler will tell you about unused 'a' and
> L1'. Use -Werror and the compilation will fail.
>
> Is there anyone here who thinks that running this program with those
> unused identifiers is not completely harmless?

In both cases the answer is, It depends.

There are scenarios where I would want the first example to compile
successfully and without any complaints. There are other scenarios
where I would want the second example to be given fatal errors during
compilation. Good compilers provide a range of options, knowing that
different circumstances call for different compilation outcomes.
Even if you want the same set of error and warning conditions in
every single compile that you do, other people don't. So you better
get used to the idea of setting the various options the way you want
them, or else write your own compiler and discover that no one else
will use it because it doesn't offer any way to select the particular
sets of choices they need for the various compilation scenarios that
are important to what they're doing.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [snip discussion of a program that divides by zero]
>
>> An implementation can refuse to translate the program, but not
>> because undefined behavior occurs. The undefined behavior here
>> happens only when the program is executed, but just compiling the
>> program doesn't do that. No execution, no undefined behavior.
>> Still the program may be rejected, because it is not strictly
>> conforming (by virtue of having output depend on the undefined
>> behavior if the program is ever run).
>
> Just to be clear, would you say that a conforming hosted implementation
> may reject this program:
>
> #include <limits.h>
> #include <stdio.h>
> int main(void) {
> printf("INT_MAX = %d\n", INT_MAX);
> }
>
> solely because it's not strictly conforming?

My understanding of the C standard is that a hosted implementation
may choose not to accept the above program and still be conforming,
because this program is not strictly conforming. (Please assume
subsequent remarks always refer to implementations that are both
hosted and conforming.)

Also, assuming we have ruled out cases involving #error, a conforming
implementation may choose not to accept a given program if and only if
the program is not strictly conforming. Being strictly conforming is
the only criterion that matters (again assuming there is no #error) in
deciding whether an implementation may choose not to accept the
program in question.

I'm guessing that what you mean by "may reject" is the same as what
I mean by "may choose not to accept". I'd like to know if you think
that's right, or if you think there is some difference between the
two. (My intention is that the two phrases have the same meaning.)

Does the above adequately address the question you want answered?

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [snip discussion of a program that divides by zero]
>>
>>> An implementation can refuse to translate the program, but not
>>> because undefined behavior occurs. The undefined behavior here
>>> happens only when the program is executed, but just compiling the
>>> program doesn't do that. No execution, no undefined behavior.
>>> Still the program may be rejected, because it is not strictly
>>> conforming (by virtue of having output depend on the undefined
>>> behavior if the program is ever run).
>>
>> Just to be clear, would you say that a conforming hosted implementation
>> may reject this program:
>>
>> #include <limits.h>
>> #include <stdio.h>
>> int main(void) {
>> printf("INT_MAX = %d\n", INT_MAX);
>> }
>>
>> solely because it's not strictly conforming?
>
> My understanding of the C standard is that a hosted implementation
> may choose not to accept the above program and still be conforming,
> because this program is not strictly conforming. (Please assume
> subsequent remarks always refer to implementations that are both
> hosted and conforming.)
>
> Also, assuming we have ruled out cases involving #error, a conforming
> implementation may choose not to accept a given program if and only if
> the program is not strictly conforming. Being strictly conforming is
> the only criterion that matters (again assuming there is no #error) in
> deciding whether an implementation may choose not to accept the
> program in question.
>
> I'm guessing that what you mean by "may reject" is the same as what
> I mean by "may choose not to accept". I'd like to know if you think
> that's right, or if you think there is some difference between the
> two. (My intention is that the two phrases have the same meaning.)
>
> Does the above adequately address the question you want answered?

I'm not sure. As I recall, I gave up on trying to understand what you
think "accept" means.

N1570 5.1.2.3p6:

A program that is correct in all other aspects, operating on correct
data, containing unspecified behavior shall be a correct program and
act in accordance with 5.1.2.3.

Does that not apply to the program above? How can it do so if it's
rejected (or not "accepted")?

The same paragraph says that "A *conforming hosted implementation* shall
accept any strictly conforming program". Are you reading that as
implying that *only* strictly conforming programs must be accepted?

As a practical matter, an implementation that accepts *only* strictly
conforming programs would be very nearly useless. I don't see anything
in the standard that says a program can be rejected purely because it's
not strictly conforming, and I don't believe that was the intent.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 11/02/2024 00:40, vallor wrote:
>
> ("Is there anyone here who thinks that" bart's continuous
> complaining about options to gcc deserve any merit?)
>
The compiler should be invoked with

gcc foo.c

Anything else represents a failure and makes it harder to use, and might
mean that the program fails to compile properly if someone fiddles with
or doesn't understand the command lines . An option is compromise, not
an added beauty.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 11/02/2024 11:01, Malcolm McLean wrote:
> On 11/02/2024 00:40, vallor wrote:
>> ("Is there anyone here who thinks that" bart's continuous
>> complaining about options to gcc deserve any merit?)
>>
> The compiler should be invoked with
>
> gcc foo.c
>

As a first stab, I'd use:

gcc -std=c11 -pedantic -W -Wall -Wextra -Werror foo.c

and try very hard to fix any/all warnings.

On 11/02/2024 00:44, Thiago Adams wrote:
> Em 2/10/2024 6:49 PM, Kaz Kylheku escreveu:
>> On 2024-02-10, bart <bc@freeuk.com> wrote:
>>>     #include <stdio.h>
>>>     int main(void) {
>>>       int a;
>>>       L1:
>>>       printf("Hello, World!\n");
>>>     }
>>>
>>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>>> 'L1'. Use -Werror and the compilation will fail.
>>>
>>> Is there anyone here who thinks that running this program with those
>>> unused identifiers is not completely harmless?
>>
>> Unused warnings exist because they help catch bugs.
>>
>>    double distance(double x, double y)
>>    {
>>      return sqrt(x*x + x*x);
>>    }
>
>
> Unused warning is a good sample to explain my point of view.
> I want a "warning profile" inside the compiler to do a "automatic code
> review".
> The criteria is not only complain about UB etc..the criteria is the same
> used by humans (in the context of the program, how critical etc) to
> approve or not a code.
>

While I appreciate the desire here, it is completely impossible in
practice. There are two main hinders. One is that different people
want different things from code reviews - code that is fine and
acceptable practice for one group or on one project might be banned
outright in another project or group. The other is that code reviewers
generally know more than you can express in code (even if you have a
language that supports assumptions, assertions, and contracts), and this
knowledge is important in code reviews but cannot be available to
automatic tools.

The best that can be done, is what is done today - compilers have lots
of warnings that can be enabled or disabled individually. Some are
considered important enough and universal enough that they are enabled
by default. There will be a group of warnings (gcc -Wall) that the
compiler developers feel are useful to a solid majority of developers
without having too many false positives on things the developers
consider good code. And there will be an additional group of warnings
(gcc -Wall -Wextra) as a starting point for developers who want stricter
code rules, and who will usually then have explicit flags for
fine-grained control of their particular requirements.

And beyond that, there are a variety of niche checking tools for
particular cases, and large (and often expensive) code quality and
static checking tool suites for more advanced checks.

On 11/02/2024 01:02, bart wrote:
> On 10/02/2024 21:49, Kaz Kylheku wrote:
>> On 2024-02-10, bart <bc@freeuk.com> wrote:
>>>     #include <stdio.h>
>>>     int main(void) {
>>>       int a;
>>>       L1:
>>>       printf("Hello, World!\n");
>>>     }
>>>
>>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>>> 'L1'. Use -Werror and the compilation will fail.
>>>
>>> Is there anyone here who thinks that running this program with those
>>> unused identifiers is not completely harmless?
>>
>> Unused warnings exist because they help catch bugs.
>>
>>    double distance(double x, double y)
>>    {
>>      return sqrt(x*x + x*x);
>>    }
>>
>> The diagnostic will not catch all bugs of this type, since just one
>> use is
>> enough to silence it, but catching something is better than nothing.
>
>> Removing unused cruft also helps to keep the code clean. Stray material
>> sometimes gets left behind after refactoring, or careless copy paste.
>> Unused identifiers are a "code smell".
>
> This is a different kind of analysis. IMV it doesn't belong in a routine
> compilation, just something you do periodically, or when you're stuck
> for ideas.
>

Absolutely not!

You want these checks as soon as possible. You don't want to find out
about a bug because someone complained about glitches and problems in
the delivered system - you want to find out about it as soon as you
wrote it.

If your static error checking, or linting, is not done as part of the
compile, it should be done /before/ the compilation. Not as an
afterthought when you are bored!

You can have extra levels of checking and simulation run separately if
they take significantly longer to run - just like running test suites
and regression tests. It is not uncommon in large development groups to
have big and advanced checks and reports done when code is checked into
development branches of the source code control system - and passing
these is a requirement before moving the code to the master branch. If
these big checking systems take a couple of hours to run, then you can't
run them for every change - but you can run them overnight.

Checking for unused variables takes a couple of milliseconds, and should
always be done.

> In your example, maybe you did want x*x*2, and the 'y' is either a
> parameter no longer needed, or not yet needed, or temporarily not used.
>
> So it is not 'obviously wrong', and by itself, not using a parameter is
> harmless.
>
> I'm looking for a result from a compiler which is either Pass or Fail,
> not Maybe.
>
Early on in a project, you expect to have lots of things like this. You
can temporarily disable such warnings that come up a lot. As your code
solidifies, you enable them again. And once you have got code that
looks like a something worth testing, you enable "-Werror" so that all
warnings are treated as fatal errors - that way, none will be missed as
you build the code.

On 11/02/2024 02:46, Kaz Kylheku wrote:
> On 2024-02-11, bart <bc@freeuk.com> wrote:

>> This is a different kind of analysis. IMV it doesn't belong in a routine
>> compilation, just something you do periodically, or when you're stuck
>> for ideas.
>
> Periodically translates to never. If there are some situations you don't
> want in the code, the best thing is to intercept any change which
> introduces such, and not allow it to be merged.

I have an option in one of compilers called '-unused'. It displays a
list of unused parameter, local and global variables.

I should use it more often than I do. But in any case, it is a
by-product of an internal check where no storage is allocated for
variables, and no spilling is done for parameters.

The first unused parameter it reports on one app, is where the function
is part of a suite of functions that need to share the same set of
parameters. Not all functions will use all parameters.

Most unused non-parameters are left-overs from endless modifications.
(Temporary debugging variables are usually written in capitals so are
easy to spot.)

>> In your example, maybe you did want x*x*2, and the 'y' is either a
>> parameter no longer needed, or not yet needed, or temporarily not used.
>
> If we take a correct program and add an unused variable to it, it
> doesn't break. Everyone knows that. That isn't the point.
>
>> So it is not 'obviously wrong', and by itself, not using a parameter is
>> harmless.
>
> While it's not obviously wrong, it's not obviously right either.

> Moreover, it is a hard fact that the parameter y is not used.

> Granted, not every truth about a program is equally useful, but
> experience shows that reporting unused identifiers pays off. My own
> experience and experiences of others. That's why such diagnostics are
> implemented in compilers.

Take these declarations at file-scope:

typedef int A;
static int B;
int C;
typedef long long int int64_t; // visible via stdint.h

They are not used anywhere in this translation unit. gcc will report B
being unused, but not the others.

'C' might be used in other translation units; I don't know if the linker
will pick that up, or maybe that info is not known to it.

A and int64_t can't be reported because the declarations for them may be
inside a header (as is the case for int64_t) used by other modules where
they /are/ used.

But if not, they could also indicate errors. (Maybe there is also
'typedef float D', and some variable should have been type A not D.)

So potentially useful information that you say is important, but can't
be or isn't done by a compiler.

(This where whole-program compilers like the ones I do come into their own.)

>> I'm looking for a result from a compiler which is either Pass or Fail,
>> not Maybe.
>
> Things are fortunately not going to revert to the 1982 state of the
> art, though.
>
> The job of the compile is not only to translate the code or report
> failure, but to unearth noteworthy facts about the code and remark on
> them.

That's rubbish. People are quite happy to use endless scripting
languages where the bytecode compiler does exactly that: translate
source to linear bytecode in a no-nonsense fashion.

Those are people who want a fast or even instant turnaround.

Some of use want to treat languages that target native code in the same
way; like scripting languages, but with the benefit of strict
type-checking and faster code!

>>> With the unused warnings, it got diagnosed.
>>
>> So you use the linty options when you're stuck with a bug, as I suggested.
>
> The point is, I would likely not have found that bug to this day without
> the diagnostic. You want to be informed /before/ the bug is identified
> in the field.

So you run that option (like -unused in my product), /before/ it gets to
the field.

I can't routinely use -unused for the 100s of compiles I might do in one
day, even if the source was up-to-date that morning with zero unused
vars, because I will be compiling part-finished or temporarily
commented-out code all the time. Eg. there might be an empty function body.

Or I've deleted the body for a rewrite, but still need the same variables.

On 11/02/2024 02:51, Keith Thompson wrote:
> vallor <vallor@cultnix.org> writes:
> [...]
>> Regarding the topic, I'm curious why there is resistance
>> to conditionals written like this:
>>
>> if( 1 == a)
>>
>> ...that is to say, with the constant first.
>>
>> I've done that in C and Perl. Are the aesthetics so
>> bad that I should quit that? Isn't it safer to write
>> it that way, so that a dropped "=" is pointed out on
>> compilation?
>
> I personally find "Yoda conditions" jarring.
>
> I'm aware that `1 == a` and `a == 1` are equivalent, but I read them
> differently. The latter asks something about a, namely whether it's
> equal to 1. The former asks something about 1, which is inevitably a
> silly question; I already know all about 1. I find that when reading
> such code, I have to pause for a moment (perhaps a fraction of a second)
> and mentally reverse the condition to understand it.
>
> Note that I'm describing, not defending, the way I react to it.
>
> Writing "=" rather than "==" is a sufficienly rare mistake, and likely
> to be caught quickly because most compilers warn about it, that it's
> just not worth scrambling the code to avoid it.
>
> If you've internalized the commutativity of "==" so well that seeing
> `1 == a` rather than `a == 1` doesn't bother you, that's fine.
> But consider that some people reading your code are likely to have
> reactions similar to mine.
>

I would second that opinion.

People who have a left-to-right language as their native tongue will
find "if (a == 1)" makes more sense, because it reads more like a normal
language sentence. It requires less cognitive effort to interpret it,
and it is therefore more likely that they will interpret it correctly.

You can of course train yourself to be familiar with other arrangements,
and they will eventually look "natural" to you. People who are used to
programming in Forth feel it makes more sense to write "a 1 = if",
because that's the Forth way.

But if you want to write code that is as clear as possible to as many
other programmers as possible (and that is a good aim, though of course
not an overriding aim), try reading the code aloud as a sentence.

And if your compiler does not immediately warn on "if (a = 1)", enable
better warnings on the compiler, or get a better compiler. Or if you
have no choice but to use a poor compiler, get a linter or use a good
compiler for linting in additional to the real target compiler.

On 11/02/2024 11:31, Richard Harnden wrote:
> On 11/02/2024 11:01, Malcolm McLean wrote:
>> On 11/02/2024 00:40, vallor wrote:
>>> ("Is there anyone here who thinks that" bart's continuous
>>> complaining about options to gcc deserve any merit?)
>>>
>> The compiler should be invoked with
>>
>> gcc foo.c
>>
>
> As a first stab, I'd use:
>
> gcc -std=c11 -pedantic -W -Wall -Wextra -Werror foo.c
>
> and try very hard to fix any/all warnings.

That sounds like an incredibly slow and painful way to code.

During development, you are adding, modifying, commenting, uncommenting
and tearing down code all the time.

C already requires you to dot all the Is and cross all the Ts because of
its syntax and type needs. Why make the job even harder?

Your command line will fail a program because this variable:

int a;

is not yet used, or you've temporarily commented out the code where it
is used.

Instead of concentrating on getting working code, you now have to divert
your attention to all these truly pedantic matters.

Have you thought of WHY you are even allowed to do gcc foo.c ?

By all means run that command line when you reach certain stages, and
certainly before you ship.

My complaint is that 'gcc foo.c' is usually too lax, but your set of
options is too draconian.

I want a compiler that allows my unused variable by default, but doesn't
allow this assignment by default:

int a;
char* b=a;

It should fail it without being told it needs to fail it. And without a
million users of gcc each having to create their own suite of options,
in effect creating their own language dialect.

On 11/02/2024 12:38, bart wrote:
> On 11/02/2024 11:31, Richard Harnden wrote:
>> On 11/02/2024 11:01, Malcolm McLean wrote:
>>> On 11/02/2024 00:40, vallor wrote:
>>>> ("Is there anyone here who thinks that" bart's continuous
>>>> complaining about options to gcc deserve any merit?)
>>>>
>>> The compiler should be invoked with
>>>
>>> gcc foo.c
>>>
>>
>> As a first stab, I'd use:
>>
>> gcc -std=c11 -pedantic -W -Wall -Wextra -Werror foo.c
>>
>> and try very hard to fix any/all warnings.
>
>
> That sounds like an incredibly slow and painful way to code.
>
> During development, you are adding, modifying, commenting, uncommenting
> and tearing down code all the time.
>
> C already requires you to dot all the Is and cross all the Ts because of
> its syntax and type needs. Why make the job even harder?

Fixing things early /is/ easier. YMMobviouslyV.

On 11/02/2024 13:24, bart wrote:
> On 11/02/2024 02:46, Kaz Kylheku wrote:
>> On 2024-02-11, bart <bc@freeuk.com> wrote:
>

>> Granted, not every truth about a program is equally useful, but
>> experience shows that reporting unused identifiers pays off. My own
>> experience and experiences of others. That's why such diagnostics are
>> implemented in compilers.
>
> Take these declarations at file-scope:
>
>    typedef int A;
>    static int B;
>    int C;
>    typedef long long int int64_t;        // visible via stdint.h
>
> They are not used anywhere in this translation unit. gcc will report B
> being unused, but not the others.
>
> 'C' might be used in other translation units; I don't know if the linker
> will pick that up, or maybe that info is not known to it.
>

Some linkers certainly can pick up this kind of thing, and use it to
discard code, data, or sections that are not needed. It's not common to
warn about unused symbols, however, since you could easily be
overwhelmed. If you have a static library, or some C files that you are
using as a library, then any given program will probably only need a
small fraction of the functions they provide - unused code and data is
then not an indication of a probably error, but a normal part of the coding.

> A and int64_t can't be reported because the declarations for them may be
> inside a header (as is the case for int64_t) used by other modules where
> they /are/ used.

Not quite.

Compiler warnings apply to a compilation, which is done on a translation
unit - generally a C file with some headers included in it. If you
write "static int B;" in a header and use it with two C files, one of
which uses the variable B and the other does not, then you'll get a
warning (with "gcc -Wall") for the one compilation but not for the other.

"int64_t" is defined in a system header. gcc (and other compilers)
treat system headers (any header included with < > brackets) differently
- most warnings are disabled for them, because they often contain lots
of things you don't need, and because they may use different styles than
you choose for your own code.

Unused typedefs don't trigger a warning in gcc (even with -Wall) unless
they are local to a function, because it's only in that case that it is
likely to be because of a bug in the code.

>
> But if not, they could also indicate errors. (Maybe there is also
> 'typedef float D', and some variable should have been type A not D.)
>
> So potentially useful information that you say is important, but can't
> be or isn't done by a compiler.
>

Warnings can never be perfect, can't catch all errors, and can't avoid
all false positives and false negatives.

> (This where whole-program compilers like the ones I do come into their
> own.)

Yes, whole-program analysis can do checks that cannot be done when
analysing individual translation units.

>
>>> I'm looking for a result from a compiler which is either Pass or Fail,
>>> not Maybe.
>>
>> Things are fortunately not going to revert to the 1982 state of the
>> art, though.
>>
>> The job of  the compile is not only to translate the code or report
>> failure, but to unearth noteworthy facts about the code and remark on
>> them.
>
> That's rubbish. People are quite happy to use endless scripting
> languages where the bytecode compiler does exactly that: translate
> source to linear bytecode in a no-nonsense fashion.

Some people might be happy with that. I am not.

To me, my main use of a compiler is a "development" tool. It helps me
develop correct code. It is entirely possible to have a compiler
separate from the linter - this was common in the early days of C, and
the most extensive static error checking is done by dedicated analysis
tools. But for a large amount of common static checking, there is a
strong overlap in the code analysis done by a checker and that done by
an optimiser - it makes sense to combine the two aspects of development.

Compilers can also be used as tools for building or installing software,
run by someone other than the developers of the software. In such
cases, the person running the compiler is far less interested in
warnings - they hope the code is bug-free when they get it. Even then,
however, warnings (as long as there are no false positives) can be
helpful in case something goes wrong.

On 11/02/2024 13:23, Richard Harnden wrote:
> On 11/02/2024 12:38, bart wrote:
>> On 11/02/2024 11:31, Richard Harnden wrote:

>>> As a first stab, I'd use:
>>>
>>> gcc -std=c11 -pedantic -W -Wall -Wextra -Werror foo.c
>>>
>>> and try very hard to fix any/all warnings.
>>
>>
>> That sounds like an incredibly slow and painful way to code.
>>
>> During development, you are adding, modifying, commenting,
>> uncommenting and tearing down code all the time.
>>
>> C already requires you to dot all the Is and cross all the Ts because
>> of its syntax and type needs. Why make the job even harder?
>
> Fixing things early /is/ easier.  YMMobviouslyV.
>
>

If it's something that needs to be fixed, or is even part of the final
product.

A lot of code may be replaced five minutes later.

A program is gradually built and converges to its final form with lots
of deviations along the way. Obviously my mileage /is/ different as I
would find it stifling for it to conform to your standards at every
single step of the way, even for code with an expected half-life
measured in seconds.

(As it happens, I write most substantial projects in a different
language, and generate a C version, if needed, all at once using a
transpiler.

The development process in that other language is more informal, yet its
compiler fails assignments between incompatible pointer types, and
ignores unused labels. The sort of sensible behaviour I'd want in a C
compiler by default.)

On 2024-02-11, bart <bc@freeuk.com> wrote:
> On 11/02/2024 02:46, Kaz Kylheku wrote:
>> On 2024-02-11, bart <bc@freeuk.com> wrote:
>
>>> This is a different kind of analysis. IMV it doesn't belong in a routine
>>> compilation, just something you do periodically, or when you're stuck
>>> for ideas.
>>
>> Periodically translates to never. If there are some situations you don't
>> want in the code, the best thing is to intercept any change which
>> introduces such, and not allow it to be merged.
>
> I have an option in one of compilers called '-unused'. It displays a
> list of unused parameter, local and global variables.

If that list is not in the standard error reporting format that
editors understand like:

foo.c:13:warning: unused variable "a"

it's going to be troublesome to use.

> I should use it more often than I do. But in any case, it is a
> by-product of an internal check where no storage is allocated for
> variables, and no spilling is done for parameters.
>
> The first unused parameter it reports on one app, is where the function
> is part of a suite of functions that need to share the same set of
> parameters. Not all functions will use all parameters.
>
> Most unused non-parameters are left-overs from endless modifications.
> (Temporary debugging variables are usually written in capitals so are
> easy to spot.)
>
>>> In your example, maybe you did want x*x*2, and the 'y' is either a
>>> parameter no longer needed, or not yet needed, or temporarily not used.
>>
>> If we take a correct program and add an unused variable to it, it
>> doesn't break. Everyone knows that. That isn't the point.
>>
>>> So it is not 'obviously wrong', and by itself, not using a parameter is
>>> harmless.
>>
>> While it's not obviously wrong, it's not obviously right either.
>
>> Moreover, it is a hard fact that the parameter y is not used.
>
>> Granted, not every truth about a program is equally useful, but
>> experience shows that reporting unused identifiers pays off. My own
>> experience and experiences of others. That's why such diagnostics are
>> implemented in compilers.
>
> Take these declarations at file-scope:
>
> typedef int A;
> static int B;
> int C;
> typedef long long int int64_t; // visible via stdint.h
>
> They are not used anywhere in this translation unit. gcc will report B
> being unused, but not the others.

These diagnostics would be nice to have. They require that the
compiler check the file provenance of the declaration.

We only want to know that the typedefs and "int C" are not used,
if those declarations are in the same file, not if they
came from a header.

You wouldn't want

#include <stdio.h>

generating warnings that you didn't use ferror, fputs, scanf, ...!

> 'C' might be used in other translation units; I don't know if the linker
> will pick that up, or maybe that info is not known to it.

C might be used in other translation units; yet it would be useful to
have a warning that C is not used in this translation unit.

But only if the declaration didn't come from a header.

>> Things are fortunately not going to revert to the 1982 state of the
>> art, though.
>>
>> The job of the compile is not only to translate the code or report
>> failure, but to unearth noteworthy facts about the code and remark on
>> them.
>
> That's rubbish.

I.e. you're disagreeing with best practices from the software
engineering field.

> People are quite happy to use endless scripting
> languages where the bytecode compiler does exactly that: translate
> source to linear bytecode in a no-nonsense fashion.

This is an informal fallacy known as whataboutism.

Since "anyone can code", legions of dilettantes use poorly engineered
tools today.

So what? Some of them also don't test or document, or use version
control. So neither should you?

"There exist plumbers who string together pipes and hope for the best,
so engineering in the area of fluid dynamics is for shit."

> Those are people who want a fast or even instant turnaround.
>
> Some of use want to treat languages that target native code in the same
> way; like scripting languages, but with the benefit of strict
> type-checking and faster code!

All static information about a program is part of type checking!

Have you heard of the Curry-Howard correspondence? In a nutshell, it's
a mathematical result which says that type systems and formal logic
are equivalent.

Type checking isn't just about rejecting when an integer argument
is given to a string parameter.

Type checking means checking logical consistencies. When a compiler
checks types, it is evaluating logic.

Any logical proposition that we can verify about a program is a type
check.

If we decide to diagnose unused variables, that's a type check.

>>>> With the unused warnings, it got diagnosed.
>>>
>>> So you use the linty options when you're stuck with a bug, as I suggested.
>>
>> The point is, I would likely not have found that bug to this day without
>> the diagnostic. You want to be informed /before/ the bug is identified
>> in the field.
>
> So you run that option (like -unused in my product), /before/ it gets to
> the field.

Then you have to estimate: how many days before releasing to the field
do you do that, based on guessing how many bugs that might uncover.

It's an extra grunt work that someone has to be assigned to.

If fixes arise out of it, they will all be root caused to earlier work
items, which are probably associated with closed work tickets. Do you
open new tickets for those, or re-open the old ones? Or just put it
under its own ticket?

If you always have all merged code in a state where there are no unused
identifiers, you don't have any of this.

> I can't routinely use -unused for the 100s of compiles I might do in one
> day, even if the source was up-to-date that morning with zero unused
> vars, because I will be compiling part-finished or temporarily
> commented-out code all the time. Eg. there might be an empty function body.

How recently and for how many years have you worked in a software
engineering team of more than five people, using tools that you didn't
cob together yourself?

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

Em 2/11/2024 9:06 AM, David Brown escreveu:
> On 11/02/2024 00:44, Thiago Adams wrote:
>> Em 2/10/2024 6:49 PM, Kaz Kylheku escreveu:
>>> On 2024-02-10, bart <bc@freeuk.com> wrote:
>>>>     #include <stdio.h>
>>>>     int main(void) {
>>>>       int a;
>>>>       L1:
>>>>       printf("Hello, World!\n");
>>>>     }
>>>>
>>>> Ramp up the warnings and a compiler will tell you about unused 'a' and
>>>> 'L1'. Use -Werror and the compilation will fail.
>>>>
>>>> Is there anyone here who thinks that running this program with those
>>>> unused identifiers is not completely harmless?
>>>
>>> Unused warnings exist because they help catch bugs.
>>>
>>>    double distance(double x, double y)
>>>    {
>>>      return sqrt(x*x + x*x);
>>>    }
>>
>>
>> Unused warning is a good sample to explain my point of view.
>> I want a "warning profile" inside the compiler to do a "automatic code
>> review".
>> The criteria is not only complain about UB etc..the criteria is the same
>> used by humans (in the context of the program, how critical etc) to
>> approve or not a code.
>>
>
> While I appreciate the desire here, it is completely impossible in
> practice.  There are two main hinders.  One is that different people
> want different things from code reviews - code that is fine and
> acceptable practice for one group or on one project might be banned
> outright in another project or group.  The other is that code reviewers
> generally know more than you can express in code (even if you have a
> language that supports assumptions, assertions, and contracts), and this
> knowledge is important in code reviews but cannot be available to
> automatic tools.
>
> The best that can be done, is what is done today - compilers have lots
> of warnings that can be enabled or disabled individually.  Some are
> considered important enough and universal enough that they are enabled
> by default.  There will be a group of warnings (gcc -Wall) that the
> compiler developers feel are useful to a solid majority of developers
> without having too many false positives on things the developers
> consider good code.  And there will be an additional group of warnings
> (gcc -Wall -Wextra) as a starting point for developers who want stricter
> code rules, and who will usually then have explicit flags for
> fine-grained control of their particular requirements.

I think it is possible having the following.
A way to specify a set of warnings/errors. It can be a string for instance.
Make some warning in this set standard.

> And beyond that, there are a variety of niche checking tools for
> particular cases, and large (and often expensive) code quality and
> static checking tool suites for more advanced checks.
>
>

Yes, I agree we can have tools, and each tool can solve the problem.

But my point in having something standardized is because we can have
"standardized safety" and "standardized mechanism to control static
analyses tools".

The same assumptions you have in on compiler you can have in another.

We can compare this approach with C++ for instance, when in C++ we have
an error and in C a warning, that means the error is part of the C++
language, it works in the same way in any compiler.

The other advantage is not having each tool with its own annotations.
Today GCC has some annotations, MSVC has SAL for instance etc.