[Mesa-dev] Add an ASSERTED macro to use in place of MAYBE_UNUSED?
Kenneth Graunke
kenneth at whitecape.org
Tue Apr 23 20:53:09 UTC 2019
On Monday, April 22, 2019 3:21:22 PM PDT Eric Anholt wrote:
> Jason Ekstrand <jason at jlekstrand.net> writes:
>
> > All,
> >
> > I've seen discussions come up several times lately about whether you should
> > use MAYBE_UNUSED or UNUSED in what scenario and why do we have two of them
> > anyway. That got me thinking a bit. Maybe what we actually want instead
> > of MAYBE_UNUSED is something like this:
> >
> > #ifdef NDEBUG
> > #define ASSERTED UNUSED
> > #else
> > #define ASSERTED
> > #endif
> >
> > That way, if you only need a parameter for asserts, you can declare it
> > ASSERTED and it won't warn in release builds will still throw a warning if
> > you do a debug build which doesn't use it. Of course, there are other
> > times when something is validly MAYBE_UNUSED such as auto-generated code or
> > the genX code we use on Intel. However, this provides additional meaning
> > and means the compiler warnings are still useful even after you've
> > relegated a value to assert-only.
> >
> > Thoughts? I'm also open to a better name; that's the best I could do in 5
> > minutes.
>
> We should delete one or the other of the current ones and not have
> different names to need to know for the same underlying function
> attribute. I'd prefer deleting MAYBE_UNUSED (UNUSED is less typing and
> the name of the underlying attribute), but would go either way.
I agree, I'd be happy to see MAYBE_UNUSED go. The actual compiler
attribute is named "unused". Jason's idea sounds interesting, too,
in that it lets us get warnings about unused code in debug builds,
but still silence release warnings about values we assert on. I'd
be okay with adding one of those and using that.
--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190423/e4d46976/attachment.sig>
More information about the mesa-dev
mailing list