Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Newsgroups | comp.std.c |
| Subject | Re: quick question regarding size_t |
| Date | 2013-01-15 22:20 -0800 |
| Organization | A noiseless patient Spider |
| Message-ID | <kfny5ftbqec.fsf@x-alumni2.alumni.caltech.edu> (permalink) |
| References | <0a1cd0f9-4f2e-4616-8d73-501f01d8a850@googlegroups.com> <kd54ab$all$1@dont-email.me> |
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.
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