As can be seen from previous commits, it's fairly easy to pass a
different type to virReportEnumRangeError() than the actual
variable is of. So far, we have a sizeof() hack to check if some
nonsensical types are not passed, e.g. it catches cases where a
function name is passed instead of an enum. Extend the hack to
check whether proper enum was passed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
src/util/virerror.h | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/util/virerror.h b/src/util/virerror.h
index ee85247433..d4b2679a09 100644
--- a/src/util/virerror.h
+++ b/src/util/virerror.h
@@ -161,16 +161,18 @@ void virReportSystemErrorFull(int domcode,
#define virReportRestrictedError(...) \
virReportErrorHelper(VIR_FROM_THIS, VIR_ERR_OPERATION_DENIED, \
__FILE__, __FUNCTION__, __LINE__, __VA_ARGS__)
-/* The sizeof(...) comparison here is a hack to catch typos
- * in the name of the enum by triggering a compile error, as well
- * as detecting if you passed a typename that refers to a function
- * or struct type, instead of an enum. It should get optimized away
- * since sizeof() is known at compile time */
+/* The ternary operator here is a hack to catch typos in the name of
+ * the enum and mismatching enum by triggering a compile error, as
+ * well as detecting if you passed a typename that refers to a
+ * function or struct type, instead of an enum. It should get
+ * optimized away since the value is constant and thus is known at
+ * compile time. */
#define virReportEnumRangeError(typname, value) \
virReportErrorHelper(VIR_FROM_THIS, VIR_ERR_INTERNAL_ERROR, \
__FILE__, __FUNCTION__, __LINE__, \
"Unexpected enum value %d for %s", \
- value, sizeof((typname)1) != 0 ? #typname : #typname);
+ value, \
+ (__typeof__(value))1 == (typname)1 && sizeof((typname)1) != 0 ? #typname : #typname)
#define virReportError(code, ...) \
virReportErrorHelper(VIR_FROM_THIS, code, __FILE__, \
--
2.41.0