🚀 go-pugleaf

> > The wording of section 3.1.2.5/6.1.2.5 of the standard clearly implies
> > that the 9 "usual" integral types are the only ones.  They consist of
> > 4 signed integer types, 4 unsigned integer types, and char -- which
> > of course can be either signed or unsigned.  Since size_t and ptrdiff_t
> > are specified respectively as unsigned or signed *integral* types, not
> > *integer* types, then an implementation could actually use char for
> > one of them ...
> 
> To get nitpicky, section 3.3.3.4 states that size_t is an
> unsigned integral type.  Section 3.1.2.5 discusses the integral
> types.  As I read it, no matter what its implementation, char is 
> neither an unsigned integral type nor a signed integral type.  Thus,
> there are 4 possibilites for size_t and ptrdiff_t.

Well, I'll back off part way.

The standard defines the terms "signed integer type", "unsigned integer
type", and "integral type", but it does not define "signed", "unsigned",
"signed integral type", or "unsigned integral type".  Therefore these
terms mean what they look like, and an integral type that is signed
is a signed integral type.

Values of char can be "treated as either signed or nonnegative integers".
In the first case, char *is* therefore a signed integral type, and could
be the type of ptrdiff_t.  However, since the second case does not use
the word "unsigned", it might be argued *not* to imply that char is then
an unsigned type; in particular, it might not have the "cannot overflow"
semantics that unsigned integer types do.  (I think it would need an
Interpretation Ruling to settle this.)  So even in an implementation where
char is not signed and is big enough, it might not be legitimate for it
to be size_t.
-- 
Mark Brader, Toronto		"It's the almost correct solutions that
utzoo!sq!msb, msb@sq.com	 are the most dangerous..."  -- Dave Eisen

This article is in the public domain.