[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] QEMU_BUILD_BUG_ON: use __COUNTER__

From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] QEMU_BUILD_BUG_ON: use __COUNTER__
Date: Tue, 31 Jan 2017 16:34:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 31 January 2017 at 15:03, Eric Blake <address@hidden> wrote:
>> On 01/31/2017 08:43 AM, Michael S. Tsirkin wrote:
>>> Some headers use QEMU_BUILD_BUG_ON. This causes a problem
>>> if the C file including that header happens to have
>>> QEMU_BUILD_BUG_ON at the same line number.
>>> Fix using a widely available extension: __COUNTER__.
>> gcc 4.3 and later; clang documents it but doesn't say when it was added.
>>> If unavailable, provide a stub.
>> What fails in our build farm if we don't provide the stub? Can we just
>> require that our compiler is new enough to have __COUNTER__, or will
>> that break some of our existing targets?
> I think the problem is not so much our build farm (which is
> I think all recent enough to postdate introduction of
> __COUNTER__) but the probability of there being users
> out there who are still using older compilers to build
> QEMU releases. We don't need to enforce compile time
> asserts on those old compilers but given that it's
> trivial to avoid actually breaking the build for them,
> why not provide the do-nothing fallback?

I don't think we actually need __COUNTER__.

If we want it, providing a fallback is nice.  However, the "expand to
nothing" fallback is syntactically unsound.  A sound fallback expands to
the exact same syntactic construct as the real thing does, in this case
a declaration.  When it doesn't, we risk parse errors.

Of course, we may decide to accept that risk.

reply via email to

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