[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: source(builtin) and read(2)
From: |
Schwarz, Konrad |
Subject: |
RE: source(builtin) and read(2) |
Date: |
Mon, 26 Mar 2007 10:57:34 +0200 |
> -----Original Message-----
> From: Clive D.W. Feather [mailto:address@hidden
> > While we're at it, I would be interested in the rational
> for "inventing"
> > ssize_t and not using ptrdiff_t instead, if anyone would care to
> > comment.
>
> size_t has to be able to hold the size of the largest object.
> It is an unsigned type.
>
> ptrdiff_t has to be able to hold the largest difference
> between two pointers; it is a signed type.
>
> The two need not be a signed/unsigned pair. For example, if a
> system has a maximum object size of 64,000 bytes, then size_t
> needs to be at least 16 bits but ptrdiff_t needs to be at
> least 17 bits. Thus it would be legitimate for size_t to be
> (16 bit) unsigned short but ptrdiff_t to be
> (32 bit) signed int.
>
> ssize_t is the signed type corresponding to size_t. In the
> above example, it is required to be signed short. It's
> possible for a legitimate subtraction of two pointers to
> generate a value that can't fit in ssize_t.
> However, because size_t and ssize_t are a signed/unsigned
> pair, they have useful properties (for example, when dealing
> with varargs lists).
Ok.
I see that e.g.,
http://www.opengroup.org/onlinepubs/009695399/functions/read.html makes
clear that "If the value of nbyte is greater than {SSIZE_MAX}, the
result is implementation-defined.", so these types of functions can't
deal with arbitrary objects (in the case that sizeof (ssize_t) < sizeof
(ptrdiff_t)) anyhow.
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. This would seem to have greater
utility than the ability to interchange ssize_t and size_t when dealing
with varargs lists.
>From C89/C99 I see that "size_t [...] is the unsigned integer type of
the result of the sizeof operator" but not that objects up to 1 <<
sizeof (size_t) * CHAR_BIT need to be supported by the implementation
(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). In fact, this is the situation in all
ABIs I have ever looked at.
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.
Was there ever any pressure from implementers for introducing ssize_t in
lieu of ptrdiff_t?
Regards,
Konrad
- Re: source(builtin) and read(2), Eric Blake, 2007/03/23
- Re: source(builtin) and read(2), Paul Eggert, 2007/03/23
- Re: source(builtin) and read(2), Bruno Haible, 2007/03/23
- Re: source(builtin) and read(2), Eric Blake, 2007/03/24
- RE: source(builtin) and read(2), Schwarz, Konrad, 2007/03/26
- Re: source(builtin) and read(2), Clive D.W. Feather, 2007/03/26
- RE: source(builtin) and read(2),
Schwarz, Konrad <=
- Re: source(builtin) and read(2), Clive D.W. Feather, 2007/03/26
- RE: source(builtin) and read(2), Nick Stoughton, 2007/03/27
- Re: source(builtin) and read(2), Clive D.W. Feather, 2007/03/27
- Re: source(builtin) and read(2), Matthew Woehlke, 2007/03/27
- RE: source(builtin) and read(2), Matthew Woehlke, 2007/03/27
- Re: source(builtin) and read(2), Paul Eggert, 2007/03/29
- Re: source(builtin) and read(2), Geoff Clare, 2007/03/30