Haai,
"Anders Andersson" <pipat...@gmail.com> wrote:
> On Tue, Feb 25, 2020 at 12:14 PM <zeurk...@volny.cz> wrote:
>>
>> First of all, let us reflect upon the definition of size_t in C99.
>>
>> > size_t
>> > which is the unsigned integer type of the result of the sizeof
>> > operator;
>>
>> That's not very specific. It kind-of implies that SIZE_MAX (defined
>> later in the standard) is the largest possible offset, but not
>> necessarily the largest possible address. This reeks of i86 real mode
>> semantics, obsolete (for general-purpose machines) already when the
>> PDP-11 was new.
>
> I think it's pretty clear, size_t is for the size of objects, not for
> offsets or pointers.
At least in C, the difference between sizes, offsets, and addresses are
semantic in nature. Even B, as meunderstands, treats memory as a flat
array (just of words instead of bytes).
> The C standard frowns upon mixing up pointers and
> integers, to much grief from low-level developers.
Menoticed that too. Given the nature and background of C, it's pretty
weird (not to say inappropriate) for 'the standard'(tm) to do so.
>> Is SIZE_MAX guaranteed to *not* be greater than the highest address?
>
> I'm almost certain that C99 offers no such guarantees, since a pointer
> to a float does not have to be the same size as a pointer to int, for
> example. Maybe if you're being a little more specific. There are some
> exceptions for void * and char *.
>
> In fact, the standard only *recommends* that implementations keep
> SIZE_MAX as small as possible but not smaller. Since it is only a
> recommendation, it can be inferred that the standard acknowledges that
> an implementation with SIZE_MAX > highest address is valid.
Mesupposes that's tolerable, as long as sizeof() indeed never returns a
value greater than the largest address... mehas observed no such
guarantee either, however.
> "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."
Yes, menoticed. Strange for the standard to suddenly group sizes and
addresses (address "diffs" even!) together. Quite schizophrenic if you
ask me...
> Or my interpretation: "Just because there is now a new and fancy
> 64-bit long long in C99 doesn't mean that you should make size_t a
> long long just because you can, because it's pointless if your
> compiler/target only has a 32-bit address space."
The issue mebumped into was that SIZE_MAX being an arbitrary value, with
no specified relation to the highest address, makes some compat code
pretty messy. Hence mehoped that there was some kind of guarantee; megot
the answer mefeared.
Thanks, your answer was quite helpful.
Baai,
--zeurkous.
--
Friggin' Machines!
