Re: C types, was What attributes of a programming language simplify its use?

Keith Thompson <Keith.S.Thompson+u@gmail.com>
Thu, 08 Dec 2022 18:35:07 -0800

          From comp.compilers

Related articles
| List of all articles for this month |
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.compilers
Date: Thu, 08 Dec 2022 18:35:07 -0800
Organization: None to speak of
References: 22-12-001 22-12-003 22-12-004 22-12-007 22-12-010 22-12-011 22-12-012
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="74427"; mail-complaints-to="abuse@iecc.com"
Keywords: types
Posted-Date: 10 Dec 2022 16:24:47 EST

Hans-Peter Diettrich <DrDiettrich1@netscape.net> writes:
> On 12/8/22 2:53 AM, Keith Thompson wrote:
>> Hans-Peter Diettrich <DrDiettrich1@netscape.net> writes:
>>> On 12/6/22 6:56 PM, Keith Thompson wrote:
>> [...]
>>>> "int int" is a syntax error.
>>>
>>> I could not find in the (older) C++ grammar why "int int" should be a
>>> *syntax* error. Aren't both "int" and "long" simple-type-specifier's
>>> which can occur multiple times in a decl-specifier-seq?
>>
>> No, there are specific rules that specify the way they can be used.
>> In the 2011 ISO C standard standard (I use the draft from
>> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), the valid
>> type specifiers are listed in section 6.7.2.
>
> Thanks for the link :-)
>
>> 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. Each list of type
>> specifiers shall be one of the following multisets (delimited
>> by commas, when there is more than one multiset per item);
>> the type specifiers may occur in any order, possibly intermixed
>> with the other declaration specifiers.
>
> So let me repeat my questions:
>
> - Why is "int int" a syntax error? "At least one..." allows for more
> than one type-specifier in declaration-specifiers (6.7).


Sorry, my mistake. It's not a syntax error (a violation of a syntax
rule). It's a constraint violation. "int int" and "long long" are both
permitted by the grammar. The "Each list of type specifiers shall be
one of the following ..." wording forbids "int int" while allowing "long
long".


The paragraph I quoted above is a *constraint*. The C standard requires
at least one diagnostic for any program that violates either a
constraint or a syntax rule.


C compilers aren't required to treat the two kinds of violations
differently. As gah4 points out, a compiler might use a more permissive
grammar and flag some syntax errors as if they were constraint
violations, particularly for constructs that it might accept with more
permissive options.


> - What's "long int long"? My current (Arduino) C++ compiler doesn't flag
> it as an error.


Because it isn't an error. "long int long" is equivalent to "long long
int", since "the type specifiers may occur in any order". (The
individual keywords "int" and "long" are type specifiers; "long long
int" is a list of 3 type specifiers, making up a *type name* (6.7.7).


(Of course the fact that you *can* write "long int long" or "double
_Complex long" doesn't mean you *should*.)


> DoDi
> [This is getting close to comp.lang.c but I'm OK with a little more
> discussion of the design decisions in C's very messy declarations. -John]


Agreed. Early C was simpler, though the general principle that
declaration (more or less) follows usage made the declaration syntax a
bit unusual. As new features like typedef and long long were added and
wedged into the existing syntax, the rules had to be made more
elaborate. The standard has formal rules that describe features that
evolved rather informally (like the fact that "typedef" is syntactically
a storage class).


I'm sure the language would be different if backward compatibility were
not an issue.


--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.