Re: [Xen-devel] [PATCH 1/5] xen: add ssize_t

[Jean Guyader <jean.guyader@xxxxxxxxx>]

On 9 August 2012 11:39, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 09.08.12 at 12:19, Jean Guyader <jean.guyader@xxxxxxxxx> wrote:
>> On 9 August 2012 10:51, Tim Deegan <tim@xxxxxxx> wrote:
>>> At 15:47 +0100 on 06 Aug (1344268059), Jean Guyader wrote:
>>>> On 6 August 2012 09:08, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> >>>> On 03.08.12 at 21:50, Jean Guyader <jean.guyader@xxxxxxxxxx> wrote:
>>>> >
>>>> > Without finally explaining why you need this type in the first place,
>>>> > I'll continue to NAK this patch. (This is made even worse by the fact
>>>> > taht the two inline functions in patch 5 that make use of the type
>>>> > appear to be unused.)
>>>> >
>>>>
>>>> Understood. I'll switch to use long instead of ssize_t in my
>>>> forthcoming patch serie.
>>>
>>> Please use an explicitly 64-bit type - AFAICS you're holding the sum of
>>> some 64-bit length fields.
>>>
>>
>> Ok but ssize_t is kind of a funny one. It should accept everything
>> that size_t can accept + negative values.
>
> No. It's the same relation as between e.g. "signed int" and
> "unsigned int". Value preserving conversions are only guaranteed
> for non-negative values fitting both types.
>

ssize_t is a *signed* type, I was wrong by saying that it should
accept all the range of a size_t, it allows only
a subset of it. read/write used ssize_t as a return type.

>From man 2 read:
If count is zero, read() returns zero and has no other results. If
count is greater than SSIZE_MAX, the result is unspecified.

Would it be ok to claim the same thing here? i.e. if count > INT_MAX
the result is unspecified.

Jean

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel