On Tue, Feb 25, 2020 at 12:14 PM <zeurk...@volny.cz> wrote: > > Haai, > > The definition of size_t keeps biting me. > > Some background: in nnx, me's been using the equiv of caddr_t for > counts. This works well; yet, while writing against existing code that > uses size_t, an issue has surfaced. > > 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. The C standard frowns upon mixing up pointers and integers, to much grief from low-level developers. > 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. "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." 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."
