Date: Sun, 26 Oct 1997 13:56:40 +0100 (MET) From: Wolfgang Helbig <helbig@Informatik.BA-Stuttgart.DE> To: ache@nagual.pp.ru (=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=) Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/diff system.h Message-ID: <199710261256.NAA07666@rvc1.informatik.ba-stuttgart.de> In-Reply-To: <Pine.BSF.3.96.971026145508.3606A-100000@lsd.relcom.eu.net> from "[______ ______]" at "Oct 26, 97 03:03:07 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Those ctype macros are pain. General rule is that only EOF,0..255 range
> is allowed per POSIX and ANSI. It means that ctype(char) is illegal
> if char have 8bit set, because negative sign extension happens. Possible
> workarounds:
> 1) If the program assumes ASCII-only, test isascii() before any ctype
> macro call.
isascii() is a non ISO-C extension. So better yet we change the
program in question to make it independent of this bogus assumption.
> 2) Add (unsigned char) cast to all ctype macros calls. Direct cast mask
> possible programmer errors like ctype(s) instead of ctype(*s).
2a) Pass an unsigned char (or int with its value in EOF, 0..UCHAR_MAX)
right away, i. e. change the definition ``char *foo'' to
``unsigned char *foo'' whenever possible.
> 3) Add -funsigned-char to CFLAGS, it seems to be best way unless some
> programs assume that char is signed somewhere. Many old BSD programs does.
This makes our source depend on a non portable feature of gcc, which I
think should be avoided.
So I suggest to adopt method 2) and 2a).
Wolfgang
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710261256.NAA07666>