Does your C compiler support "//"? (was Re: using structures)

[Niklas Matthies]

ISTM he's using the term offsets in the unsigned sense relative to a
base address, not in the signed sense relative to a location within a
composite object.

But offsets are by nature differences, not sizes, regardless of the
whether they are signed or not. Furthermore, array subscription is
defined in terms of pointer addition, whose reverse operation (pointer
subtraction) yields ptrdiff_t.

-- Niklas Matthies

 

[Thomas Pornin]

ISTM he's using the term offsets in the unsigned sense relative to a
base address, not in the signed sense relative to a location within a
composite object.

Exactly. In that sense, there is no such thing as a negative offset,
hence the unsigned type. Moreover, "size_t" is what memcpy() expects and
what "sizeof" returns. I tend to dislike the mixing of integral values
of distinct types, since the implicit conversions decrease readability
(in my opinion) and depend to some extent on the base architecture
characteristics.

Moreover, on some architectures, "size_t" is preferable to "ptrdiff_t"
if the algorithm to be implemented can accomodate the unsigned type. For
instance, on the 16-bit 8086 (e.g., Borland Turbo-C in so-called "small
memory model"), "size_t" is a 16-bit type but ptrdiff_t is a 32-bit
type. The code for 32-bit arithmetics is noticeably slower and bigger
than the code for 16-bit arithmetics.


--Thomas Pornin

 

[Brian Inglis]

But offsets are by nature differences, not sizes, regardless of the
whether they are signed or not. Furthermore, array subscription is
defined in terms of pointer addition, whose reverse operation (pointer
subtraction) yields ptrdiff_t.

I'm very suspicious of any operation that could result in a negative
offset from a pointer, preferring to keep pointers to beginning, end,
and current location around, adding only unsigned offsets, sometimes
carefully subtracting only using - 1. YMMV