Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Spurious diagnostic messages Date: Tue, 12 May 2015 11:29:54 -0700 Organization: None to speak of Lines: 82 Message-ID: <87pp65ejj1.fsf@kst-u.example.com> References: <7be65b03-3858-4e5b-96f2-823d40368a60@googlegroups.com> <87egn6hesd.fsf@kst-u.example.com> <871tj4glau.fsf@kst-u.example.com>

<873831g1pf.fsf@kst-u.example.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="9be37d943435275679235b07c7947eef"; logging-data="13123"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19U3BnTLGEEphptT2b4Hsfc" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:XMSIdioy6IUPvYqzThCgGwA4jVo= sha1:JioERu+vRaP+uiBV0S8rj9Cwtfw= Xref: csiph.com comp.lang.c:61921 Richard Heathfield writes: > On 12/05/15 18:11, Keith Thompson wrote: > > > >> The standard integer types are _Bool and signed and unsigned char, >> short, int, long, and long long. The integer types are those plus >> any extended integer types. (Plain char doesn't seem to fit into >> that scheme, which I find odd.) > > It /is/ odd, but for fairly unremarkable historical reasons. A char > has to be able to store, with a non-negative value, every character in > the basic execution character set. EBCDIC has some fairly important > characters with code points greater than 127. On an EBCDIC system in > which 8-bit char is considered desirable, implementations are more or > less forced to make char unsigned. > > We have some choices: > > 1) outlaw EBCDIC; > 2) force ASCII-based implementations to make char unsigned; > 3) make char at least 9 bits rather than 8; > 4) live with a weird char, like we do now. > > If we do (1), IBM will sulk. > > If we do (2), GNU, Microsoft, etc will sulk (and we'll introduce a > different anomaly, that of char being unsigned by default whereas > short, int, long, and long long, are signed by default. > > If we do (3), *everybody* will sulk. > > But if we go for (4), we don't have to change anything, which is > always a popular option. Sure, I understand all that, and I'm not suggesting a change. (I wouldn't mind requiring plain char to be unsigned, but that's probably not going to happen, and it could have performance implications for some systems.Z) If I had been writing section 6.2.5 of the standard, I'd include plain "char" in the list of standard integer types. Clearly it's standard, and integer, and a type, so excluding it seems odd. Currently, the standard defines the *standard signed integer types* as: signed char short int long long long the *standard unsigned integer types* as: _Bool unsigned char unsigned short unsigned int unsigned long unsigned long long and the *standard integer types* as the standard signed integer types and the standard unsigned integer types. 6.2.5p17 defines the category of *integer types* as the signed and unsigned integer types, plain char, and the enumerated types. So plain char is an *integer type* but not a *standard ineteger type*. Furthermore, though char is an integer type and is either signed or unsigned, it is neither a *signed integer type* nor an *unsigned integer type*. I don't think the standard uses these categories in a way that causes real problems, but I find it unnecessarily confusing. I suggest that it would have made more sense to say that plain char is either one of the standard signed integer types or one of the standard unsigned integer types (an implementation-defined choice) *or* to define the *standard integer types* as the standard signed integer types, the standard unsigned integer types, and plain char. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"