Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c > #1839

Re: quick question regarding size_t

From James Kuyper <jameskuyper@verizon.net>
Newsgroups comp.std.c
Subject Re: quick question regarding size_t
Date 2013-01-15 21:46 -0500
Organization A noiseless patient Spider
Message-ID <kd54ab$all$1@dont-email.me> (permalink)
References <0a1cd0f9-4f2e-4616-8d73-501f01d8a850@googlegroups.com>

Show all headers | View raw


On 01/15/2013 07:43 PM, John Kearney wrote:
> in the c11 spec it says in 7.19.4
> 
> "The types used for size_t and ptrdiff_t should not have an integer
> promotion rank greater than that of signed long int unless the
> implementation supports objects large enough to make this necessary"

That's "conversion", not "promotion".

> leaving aside the fact that this can't be don on LLP64 systems.

There's several key pieces of information that you need to know in order
to determine whether a given implementation conforms to 7.19p4: These
are (size_t)-1, LONG_MIN, LONG_MAX, the minimum and maximum values of
ptrdiff_t, and the size of the largest object supported by the
implementation. The notation "LLP64" doesn't directly provide any of
those pieces of information. The "64" part of "LLP64" only sets an upper
limit on LONG_MAX and the size of the largest supported object, and a
lower limit on the value of LONG_MIN. Within the permitted ranges of
those values, there are some combinations that require invocation of the
"large enough to make this necessary" clause, and others that do not,
but there's no combination that prohibits conformance with 7.19p4.

> now ptdiff_t is signed so that works but as size_t is unsigned
> doesn't that mean that on a ILP32 system even unsigned int will have
> a higher integer promotion rank than signed long int.

No, that would not be a conforming implementation of C. It is required
that int must have a lower integer conversion rank than long int, and
that a signed type and the corresponding unsigned type have the same
integer conversion rank (6.3.1.1p1 bullets 3 and 4).

> which makes me wonder is this possible on any system, well i guess it
> would be possible on 16bit systems.

To the best of my understanding, there's a very simple algorithm which
can be used by any implementation to ensure conformance with 7.19p4:

1. Decide how big the largest object will be that you want your
implementation to support. Call this size obj_max, for now.

2. Decide how big each of the standard and extended integer types
supported by your implementation will be.

3. If UINTMAX_MAX < obj_max, then your implementation can't be
conforming. Start over.

If ULONG_MAX < obj_max, then choose size_t to be any sufficiently large
unsigned type, and satisfy 7.19p4 by invoking the "large enough to make
this necessary" clause.

Otherwise, satisfy 7.19p4 by choosing size_t to be any sufficiently
large unsigned type which has a sufficiently low integer conversion
rank. There is guaranteed to be at least one such type: unsigned long.

4. If LONG_MAX < obj_max, choose ptrdiff_t to be any sufficiently large
signed type, and satisfy 7.19p4 by invoking the "large enough to make
this necessary" clause.

Otherwise, satisfy 7.19p4 by selecting ptrdiff_t to be any sufficiently
large signed type which has a sufficiently low integer conversion rank.
There is guaranteed to be at least one such type: long.
-- 
James Kuyper

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

quick question regarding size_t John Kearney <dethrophes@googlemail.com> - 2013-01-15 16:43 -0800
  Re: quick question regarding size_t James Kuyper <jameskuyper@verizon.net> - 2013-01-15 21:46 -0500
    Re: quick question regarding size_t Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-15 22:20 -0800
  Re: quick question regarding size_t Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-15 22:26 -0800

csiph-web