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: Eric Blake
Subject: Re: [Qemu-devel] [PATCH for-2.13] pc-bios/s390-ccw: size_t should be unsigned
Date: Wed, 18 Apr 2018 08:44:26 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 04/13/2018 11:59 AM, Halil Pasic wrote:

> 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've tried to get POSIX to tighten things to require that 'size_t' and
'ssize_t' must have the same rank, so that you can sanely use
printf("%zd",(ssize_t)val), but we are not there yet.

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

Indeed, until the POSIX wording is tightened, it is technically possible
(but a very poor quality of implementation, and none of qemu's
compilation platforms fall in that category) that ssize_t has a
different rank than size_t (whether or not they also have a different
width).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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