Re: source(builtin) and read(2)

[Clive D.W. Feather]

Schwarz, Konrad said:
> I see that e.g.,
> http://www.opengroup.org/onlinepubs/009695399/functions/read.html

I wasn't aware that the return type of read() had changed to ssize_t.

> so these types of functions can't
> deal with arbitrary objects (in the case that sizeof (ssize_t) < sizeof
> (ptrdiff_t)) anyhow.

No, in the case that the largest object is more than SSIZE_MAX bytes.

> If ptrdiff_t had been used as the return type for these functions, this
> restriction could have been lifted, since per definition, a ptrdiff_t
> can represent the size of all objects.

Right.

> This would seem to have greater
> utility than the ability to interchange ssize_t and size_t when dealing
> with varargs lists.

Um, I was explaining why ssize_t exists at all, and why it isn't the same
type as ptrdiff_t. I am agnostic (right now) as to the best choice for
(e.g.) the return type of read().

> From C89/C99 I see that "size_t [...] is the unsigned integer type of
> the result of the sizeof operator"

Right.

> but not that objects up to 1 <<
> sizeof (size_t) * CHAR_BIT need to be supported by the implementation

There is no such requirement. The only requirement is that the largest
supported object is no more than SIZE_MAX bytes.

And, in fact, I have a vague memory that WG14 didn't even agree on that;
there certainly was a school of thought that you can have larger objects,
you just can't invoke sizeof() on them.

> (e.g., in the above example, the implementation could defined the
> maximum object size as 1 << 15 bytes, and then ptrdiff_t and size_t
> could be a signed/unsigned pair).

Yes.

> Technically, having sizeof (ptrdiff_t) != sizeof (size_t) seems wrong
> for a wide class of CPU architectures, because both at some point should
> reflect the width of the registers used for addressing.

Not necessarily - ptrdiff_t values involve arithmetic on addresses, which
may involve another type of register. And, even if it does reflect the
width as you suggest, then the implementation just has to work around it.

> Was there ever any pressure from implementers for introducing ssize_t in
> lieu of ptrdiff_t?

I don't recall.

-- 
Clive D.W. Feather  | Work:  <address@hidden>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <address@hidden>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
THUS plc            |                            |