Re: [Qemu-devel] [PATCH] block: Explicitly specify 'unsigned long long' for VHDX 64-bit constants

[Laszlo Ersek]

On 03/14/14 18:08, Peter Maydell wrote:
> On 14 March 2014 16:35, Laszlo Ersek <address@hidden> wrote:
>> On 03/14/14 17:26, Peter Maydell wrote:
>>> On 14 March 2014 16:17, Laszlo Ersek <address@hidden> wrote:
>>>> "Unsigned long long" is a gnu-ism for C89. It's a standard part of C99.
>>>> Last time I checked, qemu used the gnu89 dialect on all build hosts
>>>> except SunOS.
>>>
>>> HACKING says we use C99...
>>
>> HACKING lies then :)
>>
>> grep for "std=c99" or "std=gnu99". You will find no hits for the former,
>> and one hit for the latter, when the build host is SunOS. (Or just grep
>> for '-std='.)
>>
>> In gcc-4.8.2, -std still defaults to gnu89.
> 
> HACKING says what we intend. If we need to pass an argument
> to gcc to get it to accept C99 constructs we should fix
> configure.

I agree 100%.

However, it wouldn't be an immediate, transparent change. For example,
out-of-range left-shifting for a signed int is explicitly undefined
behavior in C99 (6.5.7p4) -- equally for shifting left a negative value
-- and the argument has been made before that C89 does *not* say this.

(Actually I think that it's undefined just the same in C89 -- undefined
by omission. See 3.16, "... by the omission of any explicit definition
of behavior...")

IOW I welcome your proposal, but such a step will make patches like your own

  [Qemu-devel] [PATCH 00/12] Avoid shifting left into sign bit

very necessary, not just a convenience to sanitize warnings that only
clang emits today.

In any case, I'd propose gnu99 rather than c99, because c99 might not be
a superset of gnu89. In some aspects it would be a step forward, but in
others it could be a step back. Gnu99 only goes forward. (Gnu99 is
promised as the next gcc default.)

Personal note: if qemu moves to c99 or gnu99, as per -std=, I want a
personal license to use constants like 0u and 1u in the code wherever I
want; no style complaints. Deal? :)

Thanks
Laszlo