🚀 go-pugleaf

In article <31547BB8.31D7@iadfw.net>, Larry Weiss <lfw@iadfw.net> wrote:
>Mark Brader wrote:
>> 
>> lfw@iadfw.net writes:
>> > Mike Rubenstein wrote:
>> >  > You've missed a rather subtle point.  Such extensions are legal but
>> >  > they do not introduce integer types.  The standard defines the signed
>> >  > integer types as being signed char, short int, int, and long int (and
>> >  > similarly for unsigned integer types).
>> 
>> > It must be pretty subtle!
>> 
>> Not at all.
>> 
>> > Can you cite specific Clause references ...
>> 
>> It's in 6.1.2.5/3.1.2.5:
>> 
>> # There are four "signed integer types", designated as signed char,
>> # short int, int, and long int ...
>> 
>> It says four, not four or more.
>> 
>> # For each of the signed integer types, there is a corresponding
>> # (but different) "unsigned integer type".
>> 
>> It is true that size_t is specified by 6.3.3.4/3.3.3.4 as having an
>> "unsigned integral type" rather than "unsigned integer type", but the
>> draft Record of Reponse 2 confirms that these terms were not intended
>> to be distinguished.
>> 
>> Thus if x is of type size_t, printf ("%ul\n", (unsigned long) x); is
>> safe under the present standard.
>> --
>
>
>Let me try one more time to understand what makes an extension "legal"
>and what makes an extension "impossible".   
>
> Am I correct to understand that it is impossible for an implementation
>to define an extension that introduces new integer types?  (I'm pretty sure
>answer if "yes" for the above stated reasons).

In general, extensions may be added, and the implementation remain
conforming, as long as the strictly conforming programs are translated
correctly.  The cited paragraphs define what is meant by
"unsigned integral type" in the Standard.  Certainly more data types,
including what otherwise would be called integral types, can be added
to the implementation, but when the Standard says that a type is an
unsigned integral type, it is referring to the closed definition of
unsigned integral type in the Standard.  

The ability to cast a size_t to unsigned long without loss of value is
an example of the value of this interpretation.  Note that the
definition of size_t does not allow for overflow, as with ptrdiff_t,
so that the type of size_t constrains the maximum allowable object
size, IMO.

Thad