Follow-up Comment #2, bug #62230 (project findutils):
I suppose that's an alternative, but I don't think that making it explicitly
unspecified is the best way to help users. It seems like a way to allow
programmers to (unconsciously) shift blame onto any users who "do the wrong
thing" and then encounter problems if/when a new conversion is added. It would
be much better if programmers prevented such problems in the first place
whenever possible.
A fatal error when given invalid instructions is the only/best(?) way to
ensure that new conversions can be added without breaking anyone's existing
use. But it's too late for that. It should have been done when -printf was
added (no offense meant, I'm sure it seemed like a good idea at the time).
Since it wasn't done then, the next best thing is to at least make the
documentation accurately reflect the existing behaviour(?).
Perhaps a deprecation warning for a decade or so, eventually replaced with a
fatal error would really be the next best thing.
The problem with trying to prevent assumptions by documenting that the
behaviour is explicitly unspecified, is that users can make assumptions
without reading the documentation (whatever it says). But you can't easily
ignore fatal errors. :-)
Since % at the end of the format string is already documented as being
undefined, and since it already results in a fatal error, its documentation
could be changed now to clearly state that it's an error.
And since % followed by an invalid conversion specifier is (incorrectly)
documented as doing something other than what it actually does, any
deprecation would be for something that is technically (almost) undocumented
behaviour. Perhaps a shorter deprecation period would be acceptable because of
that. Not sure.
Anyway, it's something to think about.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?62230>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
