Message159789
Oh, I read again the patch. There are two different cases:
* The code is really unreachable. Ex: the loop of lookdict() does never stop, return is used in the loop. Py_UNREACHABLE can be used in this case *to avoid a compiler warning*. __builtin_unreachable() helps if you have GCC, but if you don't have GCC, using return with a dummy value would be better than a Py_FatalError(). I don't think that calling Py_FatalError() does make the warning quiet.
* The code is reachable, but if it is reached, it's a bug. Ex: switch/case on the Unicode kinde of a string. I like the current solution: assert(0) + return a almost valid value, but Antoine and Benjamin don't like the "almost valid value" (and so prefer a fatal error?). We may issue a warning instead of a fatal error (e.g. write a message into stderr with fprintf ?) in release mode.
--
Using return, it gives something like:
+#ifdef NDEBUG
+#ifdef __GNUC__
+#define Py_UNREACHABLE(value) __builtin_unreachable()
+#else
+#define Py_UNREACHABLE(value) return (value);
+#endif
+#else
+#define Py_UNREACHABLE(value) do { assert(0); return (value); } while (0)
+#endif
It cannot be used if the function has no result value (void), but quite all Python functions have a result. |
|
Date |
User |
Action |
Args |
2012-05-02 11:50:06 | vstinner | set | recipients:
+ vstinner, loewis, pitrou, benjamin.peterson, ezio.melotti |
2012-05-02 11:50:06 | vstinner | set | messageid: <1335959406.76.0.4093392152.issue14656@psf.upfronthosting.co.za> |
2012-05-02 11:50:06 | vstinner | link | issue14656 messages |
2012-05-02 11:50:06 | vstinner | create | |
|