Chris H wrote:
> In message <lnk5hzmrw2.fsf@[EMAIL PROTECTED]
>, Keith Thompson
> <kst-u@[EMAIL PROTECTED]
> writes
>> Chris H <chris@[EMAIL PROTECTED]
> writes:
>>
>>> In message <8763tkptqi.fsf@[EMAIL PROTECTED]
>, Keith Thompson
>>> <kst-u@[EMAIL PROTECTED]
> writes
>>>> Chris H <chris@[EMAIL PROTECTED]
> writes:
>>>>> In message <op7hf5-cmk.ln1@[EMAIL PROTECTED]
>,
>>>>> lawrence.jones@[EMAIL PROTECTED]
writes
>>>>>> Chris H <chris@[EMAIL PROTECTED]
> wrote [re "char unsigned":
>>>>>>>
>>>>>>> ISO C90 has been superseded several times. Is it still legal?
>>>>>>
>>>>>> C90 has only been superseded once, although it has also been
amended
>>>>>> (once) and corrected (twice). The superseding document (C99) has
>>>>>> also
>>>>>> been corrected (thrice), but not amended.
>>>>>>
>>>>>> Yes, it's still valid (it was never "illegal"); 6.7.2p2 still
>>>>>> contains
>>>>>> the same text as C90 did.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> I have only eve seen one compiler that did it that way and they
>>>>> changed to the unsigned char over a decade ago. I did scan through
>>>>> the standard but missed the clause.
>>>>
>>>> What do you mean when you say that the compiler "did it that way"?
>>>
>>> The compiler's normal mode was char unsigned. Then they changed it to
>>> accept unsigned char. (and char unsigned)
>>
>> You mean there was actually a C compiler that would accept
>> "char unsigned" but reject "unsigned char"? Remarkable.
>> (Actually, I'd hesitate to call such a beast a "C compiler".
>
> Actually thinking about it: it was not char unsigned to unsigned char
> but a memory specifier that had it's order changed.
>
> So I Don't actually know a compiler that used char unsigned rather than
> unsigned char.
In 1978, unsigned, long, and short,
were all specifiers,
any one of which could be applied to type int.
The example in the 1978 K&R, section 2.2, page 34, is:
The declarations for the qualifiers look like
short int x;
long int y;
unsigned int z;
--
pete
|
