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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.08.12 at 12:48, Jean Guyader <jean.guyader@xxxxxxxxx> wrote:
> 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.

Sure, except that I think you wanted to use long and hence
LONG_MAX.

Jan


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