On Thu, 21 Nov 2024 at 02:33, Paul Eggert <egg...@cs.ucla.edu> wrote:
there's little reason for Bash's non-POSIX mode to differ. > 1. One person's "failure to fail" is another person's "useful undocumented extension". 2. There exist deployed scripts that rely on the current behaviour. Does anyone think these are not sufficient cause to retain the current behaviour as the default? I would generally welcome more stringent error checking, even a wholesale replacement of parts of the language, as long as it's opt-in and so doesn't break existing scripts. Without opt-in (either as “set -o posix”, or “#!/bin/bash54”, or “shopt -s compat54”), only the likes of ShellShock justify fixes that break existing code. I know that it eventually becomes impractical to maintain support for old behaviour, but before it's retired there should be a formal deprecation process, so that users can adapt their scripts BEFORE the new behaviour becomes the default. Under that argument, "printf %d -" shouldn't report an error > Agree, we should remove that diagnostic. :-) But seriously, that wasn't an argument for why it *should* be like this; I was merely explaining how it comes to be like this, based on what the implementation does. This behaviour is entirely consistent with strtol(arg,&end,0) where you only check *end==0 and don't check end>arg. (All the strtoXXX sibling functions have the same behaviour in this regard.) At some point in the past it was deemed appropriate to add a check tantamount to “if (end==arg && posix_mode) fail();”. Clearly there was a reason then to split the behaviour; what has changed to suggest that we need to revisit that? If people really hate empty==0 so much, then we should add «shopt -s forbid_empty_zero» to enforce that consistently everywhere, rather than having some places where it works and other places where it's forbidden, with the division being a moving target. -Martin
