[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Bash 4.4 Test Discrepancy on OpenVMS

From: Chet Ramey
Subject: Re: GNU Bash 4.4 Test Discrepancy on OpenVMS
Date: Mon, 10 Oct 2016 16:01:00 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

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 address@hidden@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 */

and leave the rest of the code intact.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]