🚀 go-pugleaf

jcoffin@rmii.com (Jerry Coffin) wrote:

> In article <danpop.827188302@rscernix>, danpop@mail.cern.ch says...
> > In <MIB.96Mar18105957@gnu.ai.mit.edu> mib@gnu.ai.mit.edu (Michael I. 
> Bushnell, p/BSG) writes:
> > 
> > >You are not guaranteed that long is the widest integral type.  
> > 
> > Yes, you are.  ANSI classic 3.1.2.5:
> > 
> >     There are four signed integer types, designated as signed char, 
> >     short int, int, and long int.
> > 
> > The standard doesn't leave any place for extensions here.
> 
> Uless I'm missing something, extensions shold be perfectly legal at least if 
> their names are in the implementor's name space, or are in the user's name 
> space only if a non-standard header in included, a pragma is used, etc.
> 
> I can't see any way for a strictly conforming program to be affected by the 
> compiler supporting something like _VeryLong or __int128.  Have I missed 
> something obvious?

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).  An implementation may
introduce new types that behave like integers, but according to the
standard they are not integer types.

This is important since it guarantees, for example, that size_t is
unsigned char, unsigned short, unsigned int, or unsigned long.  An
implementation cannot define size_t as being unsigned _VeryLong
(assuming, of course, that unsigned _VeryLong is a new type).


Michael M Rubenstein