This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients benjamin.peterson, loewis, vstinner
Date 2012-04-23.23:45:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20120424014517.Horde.9sDyd6GZi1VPlemNbpdnb6A@webmail.df.eu>
In-reply-to <CAPZV6o8qFoRAn+vqLvhhGDJupLR4HBQT7P4a8dnyKqPt-uqy8A@mail.gmail.com>
Content
> Right, we currently avoid this problem by writing "assert(0)" for
> example in lookdict_split in dictobject.c. What I'm saying is that
> instead writing "assert(0)", we could use Py_UNREACHABLE.

I don't understand. The assert(0) is not there to silence any compiler
warnings, is it? Instead, ISTM that it is there to truly assert that
the code is not reached, which isn't actually obvious at all (IIUC, it's
not reached because there must be some empty slot eventually unless the
key is in there already).

Instead, ISTM that is actually the "return 0;" that should silence the
compiler warning about not having a return statement.

If that's all true, I fail to see what __builtin_unreachable would achieve:
we certainly have to preserve the return statement, for compilers not  
supporting
such a declaration.

Wouldn't this actually have the undesirable effect of complaining about
the return statement when compiling with -Wunreachable-code?
History
Date User Action Args
2012-04-23 23:45:18loewissetrecipients: + loewis, vstinner, benjamin.peterson
2012-04-23 23:45:18loewislinkissue14656 messages
2012-04-23 23:45:17loewiscreate