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

Groups > comp.std.c > #1838 > unrolled thread

quick question regarding size_t

Back to article view | Back to comp.std.c

Contents

  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

#1838 — quick question regarding size_t

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"


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

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. 

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



I presume I'm missing something here all clarifications appreciated.

thanks

[toc] | [next] | [standalone]

#1839

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

[toc] | [prev] | [next] | [standalone]

#1841

James Kuyper <jameskuyper@verizon.net> writes:

> 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.

The description LLP64 normally means 32-bit ints and longs, and
64 bit long longs, pointers, and size_t (that is, 64 value bits).
The remarks above just aren't consistent with that.  Under what
LLP64 normally means, size_t would have an integer conversion
rank larger than that of unsigned long int (which is the same
as that of signed long int).

> 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.

Sure, except it is likely that what the OP meant is that on LLP64
systems that size_t would have to have an integer conversion rank
greater than that of unsigned/signed long int, which is in fact
correct, under the usual meaning of LLP64.  Looks like a pronoun
reference problem - the word 'this' in "leaving aside the fact that
this can't be done on LLP64 systems" is an ambiguous reference, and
was understood by the reader differently from how it was (probably)
intended by the writer.

[toc] | [prev] | [next] | [standalone]

#1842

John Kearney <dethrophes@googlemail.com> writes:

> in the c11 spec it says in 7.19.4 
>
> "The types used for size_t and ptrdiff_t should not have an
> integer [conversion] rank greater than that of signed long int
> unless the implementation supports objects large enough to make
> this necessary"  [..snip..]
>
> 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 [conversion] rank than signed long int.
> [..snip..]

Type unsigned int has the same integer conversion rank as (signed)
int, and unsigned long int has the same integer conversion rank as
(signed) long int.

The rule is that unsigned types have the same integer conversion
rank as their corresponding signed types (and vice versa).

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web