On Oct 11, 2016, at 2:12 PM, Eric Blake wrote:
> On 10/11/2016 01:03 PM, Programmingkid wrote:
>
>>> +/* Mac OSX has a bug that incorrectly defines SIZE_MAX with
>>> + * the wrong type. Our replacement isn't usable in preprocessor
>>> + * expressions, but it is sufficient for our needs. */
>>>
On 11 October 2016 at 19:12, Eric Blake wrote:
> On 10/11/2016 01:03 PM, Programmingkid wrote:
>
>>> +/* Mac OSX has a bug that incorrectly defines SIZE_MAX with
>>> + * the wrong type. Our replacement isn't usable in preprocessor
>>> + * expressions, but it is sufficient for our needs. */
>>> +#
On 10/11/2016 01:03 PM, Programmingkid wrote:
>> +/* Mac OSX has a bug that incorrectly defines SIZE_MAX with
>> + * the wrong type. Our replacement isn't usable in preprocessor
>> + * expressions, but it is sufficient for our needs. */
>> +#if defined(HAVE_BROKEN_SIZE_MAX) && HAVE_BROKEN_SIZE_MA
Eric Blake writes:
> C99 requires SIZE_MAX to be declared with the same type as the
> integral promotion of size_t, but OSX mistakenly defines it as
> an 'unsigned long long' expression even though size_t is only
> 'unsigned long'. Rather than futzing around with whether size_t
> is 32- or 64-bi
On Oct 11, 2016, at 12:00 PM, qemu-devel-requ...@nongnu.org wrote:
> C99 requires SIZE_MAX to be declared with the same type as the
> integral promotion of size_t, but OSX mistakenly defines it as
> an 'unsigned long long' expression even though size_t is only
> 'unsigned long'. Rather than futz
C99 requires SIZE_MAX to be declared with the same type as the
integral promotion of size_t, but OSX mistakenly defines it as
an 'unsigned long long' expression even though size_t is only
'unsigned long'. Rather than futzing around with whether size_t
is 32- or 64-bits wide (which would be needed
