On 10/7/16 12:54 PM, Eric W. Robertson wrote:
While building and testing GNU Bash 4.4 on OpenVMS, the GNU Bash test
script issued the following difference between OpenVMS Bash produced output
and reference output for the test sub-script tests/exp8.sub (lines 28 - 31)
unset array
declare -A array
array=( [$'x\001y\177z']=$'a\242b\002c' )
echo ${array[@]@A}
Currently, the reference result expected for ALL platform implementations
for the above sequence of Bash test commands is embodied in tests/exp.right
(line 236):
declare -A array=([$'x\001y\177z']=$'a\242b\002c' )
on OpenVMS the following output is generated instead:
declare -A array=([$'x\001y\177z']=$'a¢b\002c' )
After studying the applicable sections of the relevant ISO and POSIX
standards and inspection of Bash's execution within the OpenVMS Debugger, I
have come to the conclusion that this difference arises out of an
implementation dependent difference with respect to the locale dependent
characteristics of characters in the C/POSIX locale.
You're right. VMS happens to have a character mapped to that value in
the default locale (or at least your default locale), and no other
system does. It's not a test failure; it's just an anomaly. That value
was `chosen' because it is exactly the test script submitted as a bug
report in the past.
While investigating this test discrepancy with Bash 4.4 on OpenVMS I came
across another potential source code bug relating to the expansion of the
ISPRINT() function macro. The expansion of the ISPRINT() function macro is,
in turn, partially dependent on the expansion of the IN_CTYPE_DOMAIN()
function macro. In the source code module include/chartypes.h, the function
macro IN_CTYPE_DOMAIN() does not seem to be correctly defined for platforms
not providing the isascii() function.
If you're running on a platform that doesn't provide isascii(), and the
STDC_HEADERS define doesn't evaluate to something non-zero (see below, or
look at the comment in chartypes.h), all bets are off. That
function/define is not optional (obsolescent is not optional); Posix
requires it and it's there on virtually every Unix system.
The constant 1 means you make a bet that the rest of the ctype functions
check that their arguments are valid ascii characters if it matters, and
otherwise it doesn't and you don't need to check it.
Given the normative definition of the
isascii() function in "The Open Group Base Specifications Issue 7 (IEEE Std
1003.1-2008) 2016 Edition", the current definition of the IN_CTYPE_DOMAIN()
function macro (as the literal constant expression 1) is unlikely to result
in any close approximation of correct behavior for most platforms not
implementing the isascii() function. Instead, I believe the
IN_CTYPE_DOMAIN() function macro would be better defined as follows:
Not quite. The STDC_HEADERS define, if set, means that you don't have to
guard references to the ctype macros with checks using isascii(). You'd
be better off, if you wanted to really do it, with something like:
#if !defined (isascii) && !HAVE_ISASCII
# define isascii(x) ((x) >= 0 && (x) <= 127) /* basic */
#endif
and leave the rest of the code intact.