On Tue, 2022-02-22 at 09:29 +0000, Geoff Clare via austin-group-l at The Open Group wrote: > Since all character strings are strings, it is not wrong per se.
Well.... that sounds a bit far fetched ;) > However, it could be changed to say "character strings" without > altering the requirements. I've filed https://www.austingroupbugs.net/view.php?id=1564 asking for clarification of this - in the simplest case, replacing "string" with "character string". > Neither. If there are non-character bytes in the string then the > behaviour is simply unspecified, because 2.13.1 and 2.13.2 don't > specify how they are handled. It feels that there are places in the standard, where it's (more or less) generally accepted that things are deduced indirectly, without the standard *really* saying it, like: The case what shell variables are required to hold,... where most people said it's any bytes other than NUL, because of their initialisation from env vars (and them being byte strings) or because of of command substitution being any bytes and variables needing to hold them. The above case, doesn't sound so different to me (pattern matching being able to work on variables, variables being able to hold bytes other then NUL), yet there one can apparently not make such assumptions. It's not that I'd dispute that it is as you've said... but such things l leave quite some window for uncertainty,... which is also why I requested the clarification in the above ticket. Thanks, Chris.
