qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-2.13] pc-bios/s390-ccw: size_t should be uns


From: Collin Walling
Subject: Re: [Qemu-devel] [PATCH for-2.13] pc-bios/s390-ccw: size_t should be unsigned
Date: Fri, 13 Apr 2018 14:09:55 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 04/13/2018 02:06 PM, Philippe Mathieu-Daudé wrote:
> On 04/13/2018 01:59 PM, Halil Pasic wrote:
>>>> On 04/13/2018 04:30 PM, Thomas Huth wrote:
>>>>> "size_t" should be an unsigned type - the signed counterpart is called
>>>>> "ssize_t" in the C standard instead. Thus we should also use this
>>>> The first sentence sounds like ssize_t is too a type defined by some
>>>> C standard. Is it or does ssize_t come form somewhere else?
>>> Arrr, seems like ssize_t is rather coming from POSIX than from the C
>>> standard, thanks for the hint. I'll rephrase the first sentence to:
>>>
>>> "size_t" should be an unsigned type according to the C standard, and
>>> most libc implementations provide a signed counterpart called "ssize_t".
>>>
>>> OK?
>>>
>>
>> This ssize_t seems to be an rather interesting type. For instance POSIX says
>> """
>> size_t
>>     Used for sizes of objects.
>> ssize_t
>>     Used for a count of bytes or an error indication.
>> """
>> and
>> """
>> The type ssize_t shall be capable of storing values at least in the range 
>> [-1, {SSIZE_MAX}].
>> """
>>
>> And it does not mandate SSIZE_MIN in limits (but of course mandates 
>> SSIZE_MAX.
>>
>> I don't like this 'counterpart' word here, because AFAIU these don't have to
>> be counterparts in any sense. That is SSIZE_MAX << SIZE_MAX is possible for
>> example. I'm not sure about the every positive has a negative thing, but
>> that's not important here.
>>
>> The code in question kind of uses both signed and unsigned size for
>> the same (the string). We even have a signed to unsigned comparison which
>> could result in warnings. I still think the change is OK in practice, but
>> maybe avoiding introducing ssize_t (until we really need it) is a better
>> course of action. I think uitoa can be easily rewritten so it does not
>> need the ssize_t.
>>
>> How about that?
> 
> This seems clever indeed.
> 

This whole issue stems from my misuse of size_t in the first place. If it makes
things easier, let's just make num_idx of type "signed long".

After reading this discussion, I think it makes sense to drop ssize_t. No need
to make it available for just one function unless there are strong claims to
also use this type elsewhere in the pc-bios (I can't find any).

-- 
Respectfully,
- Collin Walling




reply via email to

[Prev in Thread] Current Thread [Next in Thread]