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

Richard Stallman <[email protected]> writes:

> [[[ 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. ]]]
>
>   > > But, backwards compatibility in this instance means relaxing compiler
>   > > diagnostics, thus making the compiler less strict. This is universally
>   > > a disservice to users.
>
>   > In these absolute terms I consider this statement to be wrong.
>
>   > The alternative is not a compiler that can’t be strict, but one where
>   > strictness is opt-in.
>
> That idea sounds plausible to me.
>
> When you're working on changes in your program P, you can enable
> strictness in the compiler, and get all the diagnostics that will help
> you bring it fully up to date.
>
> Then you should release the new P with strictness disabled, to reduce
> problems for the users of P.  After all, they don't know how how it
> works internally, so it would be hard for them to fix these things --
> and we shouldn't ask them to worry about those.
>
> As Arne pointed out, even with his own program it is a burden to be
> compelled suddenly to fix problems that appeared by surprise, in code
> that functioned correctly when he was last working on that program.

Unfortunately, developers don't operate like that.

As evident from many decades of the existence of -pedantic-errors not
preventing the K&R C issues.

>   > > But, backwards compatibility in this instance means relaxing compiler
>   > > diagnostics, thus making the compiler less strict. This is universally
>   > > a disservice to users.
>
> That is somewhat extremist.  Strictness in diagnostics is a benefit
> for the program's developers, when they are working on that program.
> But the same strictness can be a pain in the neck for other users and at
> other times.
>
> How about catering to both situations?  I think we can do it.

We can, that's why -fpermissive exists.

But I do not think that suffices for proper compatibility with sources
of age that makes it plausible that non-C99 syntax was intentionally
used.

Likely, a program of that vintage makes a lot of other false
assumptions, like that pointers of different types may alias
(-fno-strict-aliasing), or that signed integer addition wraps (-fwrapv).

That's why I said that it'd be good if someone was to step up to define
what the real semantics for such a compatibility mode should be.
-- 
Arsen Arsenović

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

iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmp+NdwbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJPx
dgEAzCq+owzaESLQtmwaSxE5x5JBuw7wwpEyOmweoNuAj6MBAMRMo5Lm4Gsp/r7F
qb5kYIHNJEAg/EBgujMFXKck6CAE
=Yr9V
-----END PGP SIGNATURE-----