Re: Discussion about why GNU/Linux system upgrades cause old programs to break

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >> If I removed libraries that my copy of Emacs 32 was linked against, it'd
  > >> also "break" in the same manner, even though the Emacs 32 I have
  > >> installed was built ~18 hours ago.
  > >
  > > Please drop the sarcasm.  This is a real problem, not a joke.

  > There was no sarcasm there.

The "even though the Emacs 32 I have installed was built ~18
hours ago" sounded like sarcasm.  I apologize.

  > Not necessarily, no.  A C99+ program using K&R-exclusive syntax is,
  > however.

Could you explain precisely what it means, here, to describe a program
as "a C99+ program"?  I can imagine various possible meanings, and
that could make a difference here.

Does Emacs 27 specify an option that implies "reject K&R syntax"
or "complain about anything that doesn't satisfy the C99 spec?"

Does GCC offer an option to allow K&R function definitions along with
the features of C99, which could have been used in compiling Emacs 27?

Does GCC offer an option to specify an earlier version of C,
which might have made the compilation of Emacs 27 work?

  > >> In reality, the programs have been broken for decades, often in subtle
  > >> ways, for instance by silently being compiled into wrong code.

This talks of "the programs" and that implies a subtle shift of topic.
We don't know what those other programs were, and if we knew that,
we probably wouldn't know any details of their code.  So could we
please stick to the example we have been discussing: Emacs 27.2?
That is a concrete example and we can look at it.

Was Emacs 27.2 being compiled into wrong code
before that GCC version?  I understand that _some_ programs were,
but I am asking whether that was actually happening for _this_ program.

  > >> Were we to keep this broken status quo, of having a compiler that fails
  > >> to diagnose incorrect programs, because people, 20+ years in, were not
  > >> correcting their habits

With some programs, this may have been a matter of habit.  But not in
the case of GNU Emacs.

I intentionally kept the C code in Emacs with function definitions in
K&R syntax for the sake of compilation using old compilers on old
systems.  Those compilers did not understand C99, and sometimes not
even C89.  But that did not make it necessary for Emacs to fail with
them.

                               of writing incorrect code?

I refer to the questions above, which bear on the question of whether
Emacs 27.2 was inherently incorrect.  I think that is crucial.
If it had an error that gave wrong code all along, I think it was
indeed incorrect.  But if it didn't give wrong code, I think we should
conclude that Emacs 27.2 was not incorrect (though some other programs
with this construct may be incorrect).

  > >> In my opinion, said habits are a reason to correct the status quo to
  > >> start diagnosing incorrect code.

Do can you envision what that sounds like to a user of GCC?

  > But, indeed.  Not every K&R C program is incorrect.

  > Here's an example:

  >   ~$ gcc -x c -std=gnu89 - <<<'main(argc, argv) int argc; char **argv; { printf ("%d %s\n", argc, argv[0]); exit (0); }'
  >   <stdin>: In function ‘main’:
  >   <stdin>:1:43: warning: incompatible implicit declaration of built-in function ‘printf’ [-Wbuiltin-declaration-mismatch]
  >   <stdin>:1:1: note: include ‘<stdio.h>’ or provide a declaration of ‘printf’
  >   <stdin>:1:78: warning: incompatible implicit declaration of built-in function ‘exit’ [-Wbuiltin-declaration-mismatch]
  >   <stdin>:1:1: note: include ‘<stdlib.h>’ or provide a declaration of ‘exit’
  >   ~$ ./a.out
  >   1 ./a.out
  >   ~$ ./a.out 121 3132 12
  >   4 ./a.out
  >   ~$

This is example is somewhat of a relief.  It means the GCC developers
made an effort to continue to allow compilation of programs with K&R
function definitions.

If Emacs 27.2 had compiled with warnings like that, I'd say it was
a good outcome.

So I wonder, why was the result failure rather than such warnings.
Eli, would you like to investigate why?

      ~$ gcc -x c -std=gnu89 - <<<'main(argc, argv) int argc; char **argv; { char *x = reallocarray(strdup (argv[0]), 100, 1); printf ("%d %s\n", argc, x); exit (0); }'

What is the problem with this one?  Is it that the value of strdup is 64 bits
and reallocarray's first argument is taken as int?

This example doesn't load declarations for strdup and reallocarray.
If the header files for those were included, would that cause correct
compilation despite the K&R syntax?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)