[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