[tz] tabs vs spaces
Ian Abbott
abbotti at mev.co.uk
Fri May 3 09:44:59 UTC 2013
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 at mev.co.uk> )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
More information about the tz
mailing list