More amusing C grammer

[Colin King]

The following code also shows some amusing C grammar features:

/* typedef unsigned int uint_t ... */
int typedef unsigned uint_t;

/* defaults to int type in typedef... */
typedef int_t;

main()
{
uint_t x ;
int_t i ;
}

[Simon Biber]

Colin King wrote:

The following code also shows some amusing C grammar features:

/* typedef unsigned int uint_t ... */
int typedef unsigned uint_t;
This is just changing the order of the qualifiers, which is quite
acceptable. It's just like how there's no difference between `const char
*' and `char const *'.
/* defaults to int type in typedef... */
typedef int_t;

As far as I know, this is an example of implicit int, which was removed
in C99. The code is no longer valid C.

--
Simon.

[Skarmander]

Simon Biber wrote:

Colin King wrote:

The following code also shows some amusing C grammar features:

/* typedef unsigned int uint_t ... */
int typedef unsigned uint_t;

This is just changing the order of the qualifiers, which is quite
acceptable. It's just like how there's no difference between `const char
*' and `char const *'.

Errr... what? 'typedef' is a qualifier now?

It's one thing to say 'typedef int unsigned uint_t' is just the same.
'int typedef unsigned uint_t' is another matter. If the C grammar really
considers typedef to be in the same category as 'const'... it's weird.

Not that weirdness is weird, when it comes to C.

S.

[Simon Biber]

Skarmander wrote:

Simon Biber wrote:

Colin King wrote:

The following code also shows some amusing C grammar features:

/* typedef unsigned int uint_t ... */
int typedef unsigned uint_t;
This is just changing the order of the qualifiers, which is quite
acceptable. It's just like how there's no difference between `const
char *' and `char const *'.

Errr... what? 'typedef' is a qualifier now?

No, actually. To be more accurate, according to the C grammar, `typedef'
is a storage-class specifier. As part of a declaration, storage-class
specifiers can be mixed in any order with type specifiers, type
qualifiers, or the function specifier `inline'. See C99 6.7 and 6.7.1.
It's one thing to say 'typedef int unsigned uint_t' is just the same.
'int typedef unsigned uint_t' is another matter. If the C grammar really
considers typedef to be in the same category as 'const'... it's weird.

Not that weirdness is weird, when it comes to C.

Yes, C grammar is weird.

--
Simon.

[Skarmander]

Simon Biber wrote:

Skarmander wrote:

Simon Biber wrote:

Colin King wrote:

The following code also shows some amusing C grammar features:

/* typedef unsigned int uint_t ... */
int typedef unsigned uint_t;


This is just changing the order of the qualifiers, which is quite
acceptable. It's just like how there's no difference between `const
char *' and `char const *'.

Errr... what? 'typedef' is a qualifier now?

No, actually. To be more accurate, according to the C grammar, `typedef'
is a storage-class specifier. As part of a declaration, storage-class
specifiers can be mixed in any order with type specifiers, type
qualifiers, or the function specifier `inline'. See C99 6.7 and 6.7.1.

Completely bizarre, yet making sense in some perverse way. That would
mean that in 'typedef const volatile unsigned long int cvulong_t', the
first six words can appear in any order, right?

S.

[Dave Thompson]

On Tue, 11 Oct 2005 02:13:49 +0200, Skarmander
<in*****@dontma ilme.com> wrote:
<snip>

Completely bizarre, yet making sense in some perverse way. That would
mean that in 'typedef const volatile unsigned long int cvulong_t', the
first six words can appear in any order, right?

Yes. Placing the sc-spec (in this case typedef) anyplace other than
first is officially 'obsolescent' (aka deprecated) since C90, but was
not removed in C99. What may happen in C>=0x is unknown.

There are reasonable arguments for placing the qualifiers before type
and also reasonable arguments for placing them after, so I expect the
Standard will forever allow both. I suppose it might (be changed to)
allow only before or after but not mixed, but that probably doesn't
benefit implementors and arguably doesn't help users very much.
Moreover it 'feels' inconsistent with the feature that you can have
qualifiers in a typedef type already or add them where it is used.

Similarly there are reasonable arguments for different orders among
the qualifiers, and among the type-specs (signed long vs long singed).

- David.Thompson1 at worldnet.att.ne t