Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Untyped Variables Date: Mon, 10 Aug 2015 17:42:36 -0700 Organization: None to speak of Lines: 113 Message-ID: References: <83a58dd3-53a6-422a-8502-4fef870baf70@googlegroups.com> <8eb33dc8-5c47-4b7b-a20e-584166a50d58@googlegroups.com> <55C69FFA.7050309@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="8992"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/OoPg4Xw9jo2lvh9kiwOgc" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:vEujMN6wSORe43niH+6vEqhbGpg= sha1:YKsN8XXm178wCOZNpwag6xxiblo= Xref: csiph.com comp.lang.c:67099 David Kleinecke writes: > On Monday, August 10, 2015 at 8:23:37 AM UTC-7, Keith Thompson wrote: >> richard@cogsci.ed.ac.uk (Richard Tobin) writes: >> > In article <55C69FFA.7050309@verizon.net>, >> > James Kuyper wrote: >> > >> >>On 08/08/2015 07:06 PM, David Kleinecke wrote: >> >>... >> >>> I haven't been thinking of constraints as part of syntax. ... >> > >> >>It would be more accurate to say that some constraints constrain the >> >>syntax. >> > >> > It would make sense that a program must conform to both the grammar >> > and the constraints. >> > >> > But in the case of implicit int in C90, the "constraint" in 6.5.2 >> > explicitly allows something that is not allowed by the grammar. >> >> Interesting, so it does. >> >> For those who don't have a copy of C90, 6.5.2 covers type >> specifiers. A type specifier is one of void, char, short, >> int, etc. A declaration starts with a sequence of one or more >> declaration specifiers, each of which is a storage-class specifier, >> a type-specifier, or a type-qualifier. The constraint in 6.5.2 >> restricts the list of type specifiers to one of a list of sets >> (changed to "multisets" in C99 with the addition of long long, >> though the wording wasn't updated until C11); for example, you >> can't have "int int" or "short long" in a declaration. >> >> One of the permitted sets of type specifiers is: >> >> -- int, signed, signed int, or no type specifiers >> >> So this: >> >> x; >> >> does not satisfy the grammar, but it is permitted by the constraint. >> ("auto x;" or "static x;" is permitted by the grammar.) >> >> (Note that "x;" is ambiguous at block scope, where it could be an >> expression statement; it's unambiguous at file scope where statements >> are not permitted. I think C90 has wording to resolve the ambiguity, >> but I don't know exactly where it does so.) >> >> This is yet another reason to be glad that the implicit int rule >> is no longer with us. > > I disagree with that reading of the constraint Now that I look at it again, I think you're right, and I was wrong. C90's grammar permits a declaration with no type specifiers, such as "auto x;". The constraint in 6.5.2 doesn't permit type specifiers to be omitted where the grammar requires them. It specifies the *meaning* of a declaration with no type specifiers (namely that it's equivalent to a declaration with "int" (or "signed", or "signed int", or "int signed"). Constraints: Each list of type specifiers shall be one of the following sets (delimited by commas. when there is more than one set on a line); the type specifiers may occur in any order. possibly intermixed with the other declaration specifiers. ... -- int, signed, signed int, or no type specifiers ... Semantics: ... Each of the above comma-separated sets designates the same type, except that for bit-fields, the type signed int (or signed) may differ from int (or no type specifiers). I'm fairly sure that early C compiler did permit x; at file scope to mean the same thing as int x; gcc treats it that way (with just a warning by default), presumably for backward compatibility. > but lets all just ignore > the problem and never omit a type-specifier. Indeed. C99 omits the "or no type specifiers" wording, and adds a constraint: At least one type specifier shall be given in the declaration specifiers in each declaration, and in the specifier-qualifier list in each struct declaration and type name. > If C were perfect (IMO) "double" would be "float" and "float" would be > "short float" and "double" would not be a keyword. And "long double" would be "long float"? There's a long convention of referring to 32-bit and 64-bit floating-point as single-precision and double-precision, respectively. There are a lot of things I'd change if I wanted to make C more nearly "perfect". The names of the floating-point types aren't very high on that list. (Don't ask; the "list" is purely hypothetical.) -- 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"