On Sat, 2015 Sep 26 09:08-0700, Ben Pfaff wrote:
>
> A "char" configured as signed in EBCDIC violates the ANSI C standard,
> which says:
>
> If a member of the basic execution character set is stored in a
> char object, its value is guaranteed to be positive.
Now _that's_ a welcome bit of clarity.
While (IMO) it is reasonable to support the oddball case of negative
basic chars where the logic can be centralized, there are numerous
instances where problems arise in common C idioms that are less cleanly
addressable.
Examples that I've found so far in Gnulib include
if (getc(f) == 'x') { ... }
wchar_t buf[] = { 'a', 'b', 'c', '\0' };
> Do people actually used signed "char" with EBCDIC?
It's certainly not the default, but given the sort of history and
longevity that surround many mainframe installations, I wouldn't
be surprised if some folks do. Not that the xlc man page gives
any hint why:
-qchars={signed|unsigned}
Determines whether all variables of type char are
treated as either signed or unsigned.
The default is -qchars=unsigned.
--Daniel
--
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.
