Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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
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