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/