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

Richard Stallman <[email protected]> writes:

> Your 260-line message is too long for me to read it all.  But even in
> the beginning I see it is based on an attitude that you know better
> than the users of GCC.  That attitude is called "patronizing", and
> it is natural for users to take offense at this.

The information that you say that "I" (in air-quotes, because I wasn't
referring to myself) think that "I" "know better" than GCC users is
specifically the opinion of many GCC users.

This would seem to imply the opposite of the conclusion you've taken.

It became clear, based on bug reports, questions from users and effects
on large samples of code, over the years that users were finding GCC
accepting certain K&R C constructs (declarations without a specified
type, calls to undeclared functions, use of value-less 'return' in
non-void functions, use of 'return' with a value in void functions,
implicit conversion between any arbitrary pointer types, and parameter
declarations without types) by default more harmful than helpful.

GCC had previously accepted them for backwards compatibility, despite
them being easy to write incorrect code with by accident (for instance,
by forgetting a #include, or hitting the wrong key on the keyboard by
accident while typing a type name).

Now it does so if -fpermissive is given (and, thus, if -std=c89 or
-std=gnu89 are given, as those imply -fpermissive), or if a -Wno-error=
flag for a particular construct is given (such that the user may accept
those specifically useful to them).

This was documented at
https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors

Besides accepting those constructs, GCC was also diagnosing code using
them in C99 mode (and C11 mode and so on) since at least 2004 by default
(i.e. with just -std=gnu99/-std=c99 specified).

The C11 mode became default in 2015, thus such code would've generated a
diagnostic without any flags specified since 2015.
-- 
Arsen Arsenović

-----BEGIN PGP SIGNATURE-----

iKIEARYKAEoWIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCaoK6zRsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDIQHGFyc2VuQGFhcnNlbi5tZQAKCRBSwpQwHqLEk8Eb
AP46qiTVJ4UzNg9uWfuuVPhJraAvr0y2kh13uKrWfY0jVgEAi1cg9NF6yfKYRYJQ
bziYf46k7OIOVTBHrUvTV2LYJAw=
=YoXN
-----END PGP SIGNATURE-----