On 2013-05-03 09:46, Clive D.W. Feather wrote:
James Cloos said:
zic.c uses isascii(3) and isspace(3), so it is libc and locale dependent, although in practice the use of isascii(3) should minimize that dependence. Maybe even eliminate it.
"isascii" is not a C Standard function. The C Standard requires that all the <ctype.h> functions work with all possible values of type unsigned char and with EOF, so there is no need for "isascii".
Perhaps it can be removed now that zic.c assumes the compiler understands prototypes and stuff. It has some hackery to define "isascii" as a macro if it isn't already defined as a macro, which wouldn't work if the host implemented it as a function and only supported "isalnum" etc. in the range 0 to 127.
In the C and POSIX locales, ' ', '\f', '\n', '\r', '\t' and '\v' all are valid whitespace, as confirmed by various man pages. The freebsd man page notes that that definition comes from ISO C90.
The C Standard says that, in the "C" locale, "isspace" is nonzero for those 6 characters and zero for all others. In other locales it may be nonzero for other characters, but "isalnum(c) && isspace(c)" must always be 0.
Though as mentioned previously, zic does call "setlocale" if compiled with the HAVE_GETTEXT macro set. I guess it should really switch to the "C" locale while parsing the input, but if zic can assume that the important bits of the input (nothing between a '#' and the end of a line) is ASCII encoded, I don't think parsing it in some other locale would make any difference (unless the locale uses EBCDIC or something...).
[The above statements apply to the 1990, 1994, and 1999 editions of ISO/IEC 9899.]
-- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-