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

[Michael S. Tsirkin]

On Tue, Jan 31, 2017 at 04:34:34PM +0100, Markus Armbruster wrote:
> 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__.

How would you fix the conflict above?

> 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.

That's the best I could do.