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

On 12/8/22 11:44 PM, gah4 wrote:
> On Thursday, December 8, 2022 at 12:45:04 PM UTC-8, Hans-Peter Diettrich wrote:
>
> (snip)
>
>> 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).
>
>> - What's "long int long"? My current (Arduino) C++ compiler doesn't flag
>> it as an error.
>
>> 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]
>
> Now we can get closer to compilers.
>
> I suspect that it isn't a syntax error, though it will depend on how the
> compiler is written.


IMO it's not an error WRT the formal (syntax) grammar, but may be a
*semantic* error.


> The compiler (parser) can accept any combination of the specifiers,
> and even more than one of them, and then later the compiler decides
> that the ones given are not valid.


Here I'd distinguish between definite and accidental freedom of
compilation, where *definite* is typically marked "implementation
specific". Consider the "short" and "long" modifiers, where a compiler
writer can check for any of both but may miss the case when both are
given at the same time. The result will be kind of a modifier precedence
defined by the compiler writer. If such a problem was ever recognized,
should it result in an error message or warning only?




> There was a story many years ago, about a compiler with only one error
> message: "SYNTAX ERROR". (Likely in the days of upper case only.)
>
> In any case, it is often easier to write the parser more general than
> the actual language, and then flag them later.


That's common practice, but do we have to live with it?


> But also, the same can be done for the language standard.


I'm not sure. Can constructs like the "dangling else" be resolved in a
*formal* grammar, without changing the *language*? In this case an
informal note "applies to closest ... if" can definitely fix the issue.
[You know what i mean]




> As well as I know it, in early C variables default to int. Later, it
> was required that they be declared, but the default type was still
> int.


These were the days of separate *basic types* and *type modifiers*. At
most one basic type was allowed, and if none was given it *defaulted* to
int. Like today "long" and "long int" mean the same type.
Similarly an int could be used as a pointer, and at least in one of my
old C compilers it *defaulted* to "char*".


DoDi
[Dangling else is not hard to fix in the grammar, but I would not want to
see the combinatorial explosion if you tried to put the C type constaints
into the grammar. I have often noted that if you make a grammar more
permissive and reject invalid combinations later, you generally end up
with a compiler that is easier to understand and has better error messages,
e.g. rather than SYNTAX ERROR, "too many `int' qualifiers." -John]

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