Re: More C type errors by default for GCC 14

[Po Lu <luangruo@yahoo.com>]

Eli Schwartz <eschwartz93@gmail.com> writes:

> I expect no such thing, but I do expect that people making decisions in
> the real world acknowledge that ***they*** (and no one else) made those
> decisions of their own volition.
>
> I am unsure what "decisions made in the real world" has to do with my
> observation that this real-world decision was a decision to invest time
> and effort and money in one direction rather than another direction --
> and the rejected other direction was the one that would make them users
> of GCC who are affected by GCC decisions.

The point is, we chose not to modify GCC for various reasons, and the
changes being proposed here will cause more people to make this choice.

> I do not consider that you are being told what to do with your code.
> Your code is not being broken. You may have to update your Makefile to
                                                 ^^^^^^^^^^^^^^^^^^^^

My code is being broken.  There are thousands of Makefiles, Autoconf
files containing configure tests, and so on.

> add a flag that turns off a changed default, but that does not
> constitute being told what to do with your code, only being told what to
> do with GCC.

That's GCC trying to tell me what to do with my own code.

> Very well then, (lots of) C++ is C.
>
> But many people do in fact argue that missing function declarations do
> not, in fact, look like C. It doesn't compile in a C compiler (using
                                                     ^^^^^^^^^^

% cc -V
cc: Studio 12.5 Sun C 5.14 SunOS_i386 2016/05/31
% cc -Xs -Werror hello.c -o hello
% ./hello
hello world
the time is: 1683856188
% cat hello.c

struct timeval
{
  long tv_sec;
  long tv_usec;
};

main ()
{
  struct timeval tv;

  printf ("hello world\n");
  if (gettimeofday (&tv, 0L))
    exit (1);
  printf ("the time is: %ld\n", tv.tv_sec);
}

% 

> -Werror) either. Some of the warnings under discussion in this thread
> were never valid *anywhere*.

Really? Is that, or is that not, a C compiler?

> Some people like writing some code in one language version, and some
> code in another language version, and doing so in the same file or
> perhaps even the same function. Acknowledged. I would personally be
> afraid to do that, it seems incredibly dangerous even if in the highly
> specific case of implicit function declarations it happened to work.
>
> Because that's exactly what is going on here. Features that were valid
> C89 code are being used in a GNU99 or GNU11 code file, despite that
> ***not*** being valid GNU99 or GNU11 code.

How GCC currently behaves defines what is valid GNU C.

> The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
> make it a GNU extension. It compiles with a warning in c11 mode too,
> does that make it a c11 extension? No it does not.

Except it does?  Since the compiler is defining behavior that is
otherwise undefined (i.e. the behavior of a program after a diagnostic
is emitted after encountering an erroneous construct), it is defining
an extension.

> I am not dictating anything to you or anyone else in this paragraph,
> though? All I said was that if one writes a c89 program and tells the
> compiler that, then they will not even notice this entire discussion to
> begin with.
>
> What, precisely, have I dictated?

That people who are writing GNU C code should be forced to rewrite their
code in ANSI C, in order to make use of GNU C extensions to the 1999
Standard.

> Have I dictated to you that a c89 program can be described to the
> compiler by use of the -std=c89 flag? This seems to be a pretty standard
> understanding, to me.

No, see above.

> Correction: I am arguing by analogy that your statement: "what
> guarantees that -Wno-implicit will not be removed in the future" is
> arguing to absurdity.

The reason I asked for such a guarantee was that two important options
were in fact removed by the GCC developers in the past: -traditional and
-fwritable-strings.  So there is not exactly a good track record of
keeping useful options around, after features are made into those
arguments.

> Many people write strictly conforming program, and consider lack of
> conformance to be a coding error that must be fixed. It seems like a
> wise endeavor, frankly. I am not sure why you are challenging me to do
> so as though you think that I will be incapable of it and therefore be
> forced to concede that toggling the default diagnostic for very old code
> is a bad idea.

Really? So how many programs work when int is 16, 36, or 40 bits wide?
How many programs work when signed char has trap representations?
How many programs when char not 8 bits?

How many programs assume pointers can be converted into an integer type
without any loss of information?  How many programs assume that
pointers have only one possible integer representation?  (think lookup
tables using pointers to objects as keys)

How many programs assume NULL is all-bits-zero?  IOW, that this
initialization makes sense:

struct foo
{
  void *ptr;
  int xxxxx;
};

...

struct foo foo;
memset (&foo, 0, sizeof foo);
if (foo.ptr != 0) /* here, 0 is a null pointer constant, NOT zero */

How many programs assume that arithmetic comparisons between pointers to
different objects are defined behavior?  (think anything that involves
sorting and comparing different objects, i.e. binary trees)

And how many programs written today even work at all when `int32_t' (and
similar types) are not defined in stdint.h?

How many programs use external identifiers that require more than six
(or thirty-two) significant characters, or case significance?

A strictly conforming program cannot make ANY of these assumptions:

  A strictly conforming program shall use only those features of the
  language and library specified in this International Standard.)  It
  shall not produce output dependent on any unspecified, undefined, or
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^
  implementation-defined behavior, and shall not exceed any minimum
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and as a result, they are very rarely seen.

> However, it does appear that we are still stuck in confusion here,
> because you think that GCC is no longer able to compile such code, when
> in fact it is able to.

It won't, not by default.

> Maybe I was unclear, allow me to rephrase.
>
> If a future proposal to GCC results in GCC becoming unable to compile
> some code, then and only then should we worry about the existence of
> such a proposal.
>
> Since no such proposal has been made, it is a slippery slope fallacy to
> argue that ***this*** proposal constitutes a threat to users' ability to
> compile their code (even their implicit-function-declarations code).
>
> I do not believe it is reasonable to:
>
> - engage in tons of argumentation and insist that it's a bad move for
>   GCC 14 to change a default and add a flag to get back the old default
>
> by claiming that it would be bad for users if:
>
> - GCC 16 deletes the flag for getting back the old default

I'm sorry, but this is what people have seen repeatedly happen over the
years.  Thus,

> If it is proposed to delete the flag for getting back the old default,
> then and only then do people with old codebases have a valid complaint
> that GCC is becoming unusable for their purposes.

Being sceptical about the future is perfectly reasonable.