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.
