On 03/14/14 18:08, Peter Maydell wrote: > On 14 March 2014 16:35, Laszlo Ersek <ler...@redhat.com> wrote: >> On 03/14/14 17:26, Peter Maydell wrote: >>> On 14 March 2014 16:17, Laszlo Ersek <ler...@redhat.com> 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
