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

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 13 Apr 2018 14:09:55 -0400
Collin Walling <walling@linux.ibm.com> wrote:

> 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).
> 

+1 to just using signed long. Let's not make this needlessly complicated.