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

[Halil Pasic]

On 04/13/2018 05:50 PM, Thomas Huth wrote:
> On 13.04.2018 17:28, 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?

Regards,
Halil