This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Extension compatibility policy
Joseph S. Myers wrote:
In the case mentioned of __FUNCTION__ concatenation, (a) __FUNCTION__ was
always documented as a variable, so concatentation of it was always
undocumented and so liable to removal at any time
Yes, that's a legally sustainable position, just as it would be sustainable
to make an illegal program immediately illegal in the Ada case, but as I
said, we have to consider users as well, and telling a user that he cannot
sue you for misprepresentation or doing something wrong is not actually
helpful to the user trying to get a program running.
The great majority of users do not read all the documentation carefully.
They inherit legacy code and learn by example. Yes, if they have to sue
you, they will be on weak ground, but you have to be careful that just
as you can tell people to RTFM, they can tell you and your compiler to
get lost.
So the above kind of argument is weak.
The argument that says: extension X is in practice impossible to maintain
without severe damage to efficiency or maintainability is a much stronger
argument indeed, you have to balance the pros and cons.
A good example of this is not trying to maintain behaviors for some
undefined C situations like overflow and aliasing when optimizing
(though for aliasing, we do make a switch avalable, even though
we don't have to.
What I think is important is to try to understand and document in
advance any incompatibilities, even if they are wrt undocumented
features.