Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #382072 > unrolled thread

Is C ready to become a safer language?

Back to article view | Back to comp.lang.c

Contents

  Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 01:01 -0300
    Re: Is C ready to become a safer language? Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 04:40 +0000
      Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 05:00 +0000
      Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 09:20 -0300
        Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-08 17:02 +0000
          Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:17 -0300
            Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:19 -0300
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 09:57 -0800
        Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 09:45 -0800
          Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 14:56 -0300
    Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 04:58 +0000
      Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 21:33 -0800
    Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 20:59 -0800
      Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 09:17 +0100
        Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 09:48 -0300
          Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 14:42 +0000
          Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 16:25 +0100
            Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 13:15 -0300
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-08 21:42 +0100
        Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 08:04 -0800
          Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 16:14 +0000
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-08 08:32 -0800
            Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 08:19 +0100
              Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 07:46 +0000
                Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 09:33 +0100
                  Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 10:03 +0000
                    Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 11:17 +0100
                  Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 10:24 +0000
                    Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 11:24 +0000
                      Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:28 +0000
                        Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 14:04 +0000
                      Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 15:03 +0100
                        ustent on that. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-09 16:01 +0000
                          Re: ustent on that. David Brown <david.brown@hesbynett.no> - 2024-02-09 18:00 +0100
                            Re: ustent on that. Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-10 01:20 +0000
                    Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-09 12:45 +0000
                      Re: Is C ready to become a safer language? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:01 +0000
                        Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 15:08 +0100
                Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 08:48 -0800
          Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 08:14 +0100
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 08:28 -0800
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-09 20:15 +0100
      Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 02:28 -0800
        Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 16:15 -0800
          Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 23:22 -0800
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 00:12 -0800
              Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-11 23:48 -0800
                Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-18 15:28 -0800
                  Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-23 10:35 -0700
    Re: Is C ready to become a safer language? Richard Kettlewell <invalid@invalid.invalid> - 2024-02-08 15:37 +0000
      Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-08 13:25 -0300
    Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-08 16:30 +0000
      Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-09 17:59 -0800
        Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-10 20:22 +0000
          Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-10 21:30 +0000
          Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 21:49 +0000
            Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-10 20:44 -0300
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:06 +0100
                Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 15:43 -0300
                  Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:33 -0800
                  Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-12 11:32 +0100
            Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 00:02 +0000
              Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:39 -0800
              Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 02:46 +0000
                Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 12:24 +0000
                  Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 15:06 +0100
                  Re: Is C ready to become a safer language? Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-11 18:32 +0000
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:15 +0100
          Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 16:31 -0800
            Re: Is C ready to become a safer language? Thiago Adams <thiago.adams@gmail.com> - 2024-02-11 15:57 -0300
              Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-11 13:47 -0800
          Re: Is C ready to become a safer language? vallor <vallor@cultnix.org> - 2024-02-11 00:40 +0000
            Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 01:06 +0000
            Re: Is C ready to become a safer language? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-10 17:51 -0800
              Re: Is C ready to become a safer language? David Brown <david.brown@hesbynett.no> - 2024-02-11 13:27 +0100
            Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 19:54 -0800
              Re: Is C ready to become a safer language? vallor <vallor@cultnix.org> - 2024-02-13 06:22 +0000
            Re: Is C ready to become a safer language? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-11 11:01 +0000
              Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-11 11:31 +0000
                Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 12:38 +0000
                  Re: Is C ready to become a safer language? Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-11 13:23 +0000
                    Re: Is C ready to become a safer language? bart <bc@freeuk.com> - 2024-02-11 14:17 +0000
          Re: Is C ready to become a safer language? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-10 22:21 -0800

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#382370

On 11/02/2024 19:43, Thiago Adams wrote:
> Em 2/11/2024 9:06 AM, David Brown escreveu:
>> 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.
> 

I entirely agree that it would be nice if warnings and warning sets were 
standardised - or at least there was a subset of standard warnings 
supported.  You'd have to pick new names for the subsets, and they would 
probably have to be picked explicitly to avoid conflict with existing 
code.  But you could have a range of named string options for different 
warnings, and sets of "standard C warning levels" - "scw1", "scw2", etc.

gcc and clang already cooperate a lot with warning names.  Intel icc 
follows them.  You'd have to get MS on board to make it a reality - and 
they are the ones who would have to do a lot of work on their tools and 
IDEs, since they currently use a number system.  (It could have been 
worse - if they had used names, but different names, it would be more 
confusing.)

And for MS to be interested, and to avoid duplication of effort, you'd 
want C++ included from day one.

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

C++ diagnostics have the same rules as for C.  And the main C++ 
compilers part of the same compiler suites as the main C compilers.

The difference is that when C++ started to become mainstream, there was 
little in the way of existing code - compilers could mark bad practices 
as warnings or even errors, by default.  For C, however, there was a 
significant body of code and some code that compiled and worked would 
fail to compile if the new checks were enabled by default.  Thus the C 
compilers left them off by default.

So the reason for stricter defaults in the major C++ compilers compared 
to their C siblings is backwards compatibility for older C source code.

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

[toc] | [prev] | [next] | [standalone]

#382291

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.

[toc] | [prev] | [next] | [standalone]

#382302

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

[toc] | [prev] | [next] | [standalone]

#382306

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

[toc] | [prev] | [next] | [standalone]

#382323

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.

[toc] | [prev] | [next] | [standalone]

#382333

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.

[toc] | [prev] | [next] | [standalone]

#382339

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

[toc] | [prev] | [next] | [standalone]

#382322

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.

[toc] | [prev] | [next] | [standalone]

#382296

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

[toc] | [prev] | [next] | [standalone]

#382341

Em 2/10/2024 9:31 PM, Keith Thompson escreveu:
> 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.



I haven't checked the standard but

#if 1/0
#endif


<source>:4:6: error: division by zero in preprocessor expression
     4 | #if 1/0
       |     ~^~


stops compilation.


With constexpr in C23 I guess division by 0 will stop code generation as 
well.

[toc] | [prev] | [next] | [standalone]

#382350

Thiago Adams <thiago.adams@gmail.com> writes:
> Em 2/10/2024 9:31 PM, Keith Thompson escreveu:
>> 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.
>
> I haven't checked the standard but
>
> #if 1/0
> #endif
>
>
> <source>:4:6: error: division by zero in preprocessor expression
>     4 | #if 1/0
>       |     ~^~
>
>
> stops compilation.

Then I suggest you check the standard.  It's perfectly valid for an
implementation to choose to stop compilation if it encounters 1/0 in a
preprocessor expression, but it's not required.  "The resulting tokens
compose the controlling constant expression which is evaluated according
to the rules of 6.6."  6.6, Constraints: "Each constant expression shall
evaluate to a constant that is in the range of representable values for
its type."  So that's simply a constraint violation, requiring a
diagnostic but not requiring the translation unit to be rejected.

> With constexpr in C23 I guess division by 0 will stop code generation
> as well.

No, it merely requires a constant expression.
    constexpr int n = 1/0;
is a constraint violation, requiring a diagnostic but not requiring
rejection.

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

[toc] | [prev] | [next] | [standalone]

#382297

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

[toc] | [prev] | [next] | [standalone]

#382298

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.

[toc] | [prev] | [next] | [standalone]

#382304

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

[toc] | [prev] | [next] | [standalone]

#382324

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.

[toc] | [prev] | [next] | [standalone]

#382307

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.

[toc] | [prev] | [next] | [standalone]

#382387

On Sat, 10 Feb 2024 19:54:13 -0800, Tim Rentsch
<tr.17687@z991.linuxsc.com> wrote in <86sf1z4pwa.fsf@linuxsc.com>:

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

Thank you all for setting me straight on this.  I'll stop
my yoda-conditionals, and start using -Wall.

-- 
-v

[toc] | [prev] | [next] | [standalone]

#382315

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

[toc] | [prev] | [next] | [standalone]

#382318

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.

[toc] | [prev] | [next] | [standalone]

#382326

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.

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web