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

Richard Stallman <[email protected]> writes:

>   > > Would you please show an example for the pointer on a 64-bit platform?
>   > > And one for `long long'?  I'd like to see what sort of usage would
>   > > have this problem.
>
>   > The earlier reallocarray example was one such example.
>
> Thanks.  I remember that example, but I wasn't sure it was an example
> of this topic and these remarks.  These examples enable us to make the
> question at hand more concrete.
>
> With these examples, old programs that worked fine on 32-bit
> platforms, moving to a 64-bit platform could cause the program to fail
> grossly.  That is a bug in an abstract sense.
>
> But as long as the user keeps running it on the same 32-bit platform,
> which is quite likely to happen, it is not a bug in a concrete,
> practical sense.  On that same 32-bit platform, the program would
> never fail, except artificially if a newer GCC version refuses to
> compile it.

I intentionally also included the example with 'long long'.

I'm not aware of any actually existing machine in which the above
programs would be "correct", because on most (all actually-existing?)
machines, sizeof (int) != sizeof (long long).

Thus, the above program is unlikely to have the bug "in the abstract
sense" only.

But, I also disagree with this conception of an "abstract bug".

The rules of the language do not consider 'long long' and 'int'
compatible even if they're the same size.

Relying on this bug being "abstract" is precisely the kind of false
assumption that leads to programs having a short lifetime, as I was
saying before.

It is only possible to expect a bug remaining "abstract" if you never
change any piece of the system the bug is "abstract" in.

Please do not make such false assumptions.

> So I think the most useful behavior for GCC in these cases is to give
> just a warning when compiling for a 32-bit platform, and give an error
> when compiling for a 64-bit platform.
-- 
Arsen Arsenović

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

iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmqWqOEbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJOr
uAEAy7BqVl/F7rmR/WrLeAJu5KPfCOvLxZ4+HBmnCrz3ko0BALckQPuGzkGJ8G5k
kpXxJMerkJiK+LpVvNdWFYRglPEJ
=dJgM
-----END PGP SIGNATURE-----