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.

The find(1) manual entry says (in relation to -printf):

  "A `%' character followed by any other character is discarded, but the other character is printed"

But that's not the case. find . -printf '%Q\n' prints "%Q" for each file. According to the documentation, it should print "Q".

While the behaviour described in the documentation is arguably better than the actual documentation (not as good as an error but still better), it would probably be best to change the documentation to match the current behaviour.


A separate (not technically incorrect) point:

It also says:

  "A `%' at the end of the format argument causes undefined behaviour since there is no following character.  In some locales, it  may  hide  your door keys, while in others it may remove the final page from the novel you are reading."

When in reality, it just detects the situation and terminates with this error:

  find: error: % at end of format string

While technically OK, the documentation could just tell the truth and say that it is an error. I'm assuming that there aren't any actual locales where it decides to not be an error. :-)