[Mesa-dev] [PATCH] mesa: Define helper function to get the number of texture layers.
Francisco Jerez
currojerez at riseup.net
Wed Dec 11 10:08:06 PST 2013
Brian Paul <brianp at vmware.com> writes:
> On 12/10/2013 03:27 PM, Francisco Jerez wrote:
>> Brian Paul <brianp at vmware.com> writes:
>>[...]
>>> I'm more convinced now that we should simply have an assert there rather
>>> than unreachable().
>>>
>>> Finally, in release builds we generally don't want to crash in these
>>> situations. So IMHO, it's preferable to do something like:
>>>
>> I have the feeling that this is an orthogonal question to unreachable()
>> aborting or not. I'm not convinced that there's a "sensible" default in
>> this case, and setting one seems like trying to delay the inevitable to
>> me. An invariant of the program has been broken and it's likely that
>> something will go very wrong sooner or later. The question boils down
>> to: do we want undefined behavior now, or later? I'd rather have it
>> now, but it seems like a moot question to me...
>
> In the cases at hand, _mesa_tex_target_is_layered() and
> _mesa_get_texture_layers(), returning false/0 seem like fairly
> reasonable defaults to return and hopefully wouldn't lead to a later crash.
>
> Over the years I've seen several bug reports where someone runs their
> app and sees a bunch of _mesa_problem() error messages but the app keeps
> running and doesn't crash. I think that's preferable to just crashing
> (esp. when Mesa may be running in the X server). That's the reason I'm
> hesitant to see __builtin_unreachable() getting used in release builds
> in this particular scenario. Having X crash just because we hit a
> default switch case seems unnecessarily fragile.
>
Okay. I'll send an updated version of the texture layers patch in a
minute taking into account your feed-back.
> My second concern is this: if someday someone really does want to use
> __builtin_unreachable() in the context of unconventional flow control
> (per gcc docs), will our new-and-improved unreachable() macro still be
> the right tool for them? I worry about changing the behavior of what
> seems to be an established convention.
>
Yes, I'm pretty sure it would still be, after all the unreachable macro
doesn't have any effect other than eliminating compiler warnings [what
we would still get from the call to abort] and increasing optimization
opportunities [which are not a concern in debug builds].
> Sorry for dragging this out. Please go ahead and post a patch showing
> what you have in mind.
>
I already did [1]. Would you mind reviewing it?
[1] http://lists.freedesktop.org/archives/mesa-dev/2013-December/049902.html
> -Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 229 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131211/1a1445cc/attachment.pgp>
More information about the mesa-dev
mailing list