On Jul 14 12:39, Eric Blake wrote:
> On 07/14/2016 09:09 AM, Corinna Vinschen wrote:
> > On Jul 13 15:02, Eric Blake wrote:
> >> POSIX requires that SSIZE_MAX have the same type as ssize_t, but
> >> on 32-bit, we were defining it as a long even though ssize_t
> >> resolves to an int. It also requi
On 07/14/2016 09:09 AM, Corinna Vinschen wrote:
> On Jul 13 15:02, Eric Blake wrote:
>> POSIX requires that SSIZE_MAX have the same type as ssize_t, but
>> on 32-bit, we were defining it as a long even though ssize_t
>> resolves to an int. It also requires that SSIZE_MAX be usable
>> via preproces
On Jul 14 16:37, Ray Donnelly wrote:
> Hi,
>
> Please review and consider applying the attached patch. The commit message is:
>
> [1] states: "blkcnt_t and off_t shall be signed integer types."
> This causes pacman to fail when the size requirement
> of the net update operation is negative, inste
Hi,
Please review and consider applying the attached patch. The commit message is:
[1] states: "blkcnt_t and off_t shall be signed integer types."
This causes pacman to fail when the size requirement
of the net update operation is negative, instead it
calculated a huge positive number.
[1] http:
On Jul 13 15:02, Eric Blake wrote:
> POSIX requires that SSIZE_MAX have the same type as ssize_t, but
> on 32-bit, we were defining it as a long even though ssize_t
> resolves to an int. It also requires that SSIZE_MAX be usable
> via preprocessor #if, so we can't cheat and use a cast.
>
> If thi