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

[Markus Armbruster <armbru@redhat.com>]

Peter Maydell <peter.maydell@linaro.org> writes:

> On 31 January 2017 at 15:03, Eric Blake <eblake@redhat.com> 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.