mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-01 23:03:54 -06:00
osdep: Make MIN/MAX evaluate arguments only once
I'm not aware of any immediate bugs in qemu where a second runtime evaluation of the arguments to MIN() or MAX() causes a problem, but proactively preventing such abuse is easier than falling prey to an unintended case down the road. At any rate, here's the conversation that sparked the current patch: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg05718.html Update the MIN/MAX macros to only evaluate their argument once at runtime; this uses typeof(1 ? (a) : (b)) to ensure that we are promoting the temporaries to the same type as the final comparison (we have to trigger type promotion, as typeof(bitfield) won't compile; and we can't use typeof((a) + (b)) or even typeof((a) + 0), as some of our uses of MAX are on void* pointers where such addition is undefined). However, we are unable to work around gcc refusing to compile ({}) in a constant context (such as the array length of a static variable), even when only used in the dead branch of a __builtin_choose_expr(), so we have to provide a second macro pair MIN_CONST and MAX_CONST for use when both arguments are known to be compile-time constants and where the result must also be usable as a constant; this second form evaluates arguments multiple times but that doesn't matter for constants. By using a void expression as the expansion if a non-constant is presented to this second form, we can enlist the compiler to ensure the double evaluation is not attempted on non-constants. Alas, as both macros now rely on compiler intrinsics, they are no longer usable in preprocessor #if conditions; those will just have to be open-coded or the logic rewritten into #define or runtime 'if' conditions (but where the compiler dead-code-elimination will probably still apply). I tested that both gcc 10.1.1 and clang 10.0.0 produce errors for all forms of macro mis-use. As the errors can sometimes be cryptic, I'm demonstrating the gcc output: Use of MIN when MIN_CONST is needed: In file included from /home/eblake/qemu/qemu-img.c:25: /home/eblake/qemu/include/qemu/osdep.h:249:5: error: braced-group within expression allowed only inside a function 249 | ({ \ | ^ /home/eblake/qemu/qemu-img.c:92:12: note: in expansion of macro ‘MIN’ 92 | char array[MIN(1, 2)] = ""; | ^~~ Use of MIN_CONST when MIN is needed: /home/eblake/qemu/qemu-img.c: In function ‘is_allocated_sectors’: /home/eblake/qemu/qemu-img.c:1225:15: error: void value not ignored as it ought to be 1225 | i = MIN_CONST(i, n); | ^ Use of MIN in the preprocessor: In file included from /home/eblake/qemu/accel/tcg/translate-all.c:20: /home/eblake/qemu/accel/tcg/translate-all.c: In function ‘page_check_range’: /home/eblake/qemu/include/qemu/osdep.h:249:6: error: token "{" is not valid in preprocessor expressions 249 | ({ \ | ^ Fix the resulting callsites that used #if or computed a compile-time constant min or max to use the new macros. cpu-defs.h is interesting, as CPU_TLB_DYN_MAX_BITS is sometimes used as a constant and sometimes dynamic. It may be worth improving glib's MIN/MAX definitions to be saner, but that is a task for another day. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200625162602.700741-1-eblake@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This commit is contained in:
parent
47f0d11d21
commit
f9919116b8
7 changed files with 63 additions and 23 deletions
|
@ -236,18 +236,55 @@ extern int daemon(int, int);
|
|||
#define SIZE_MAX ((size_t)-1)
|
||||
#endif
|
||||
|
||||
#ifndef MIN
|
||||
#define MIN(a, b) (((a) < (b)) ? (a) : (b))
|
||||
#endif
|
||||
#ifndef MAX
|
||||
#define MAX(a, b) (((a) > (b)) ? (a) : (b))
|
||||
#endif
|
||||
/*
|
||||
* Two variations of MIN/MAX macros. The first is for runtime use, and
|
||||
* evaluates arguments only once (so it is safe even with side
|
||||
* effects), but will not work in constant contexts (such as array
|
||||
* size declarations) because of the '{}'. The second is for constant
|
||||
* expression use, where evaluating arguments twice is safe because
|
||||
* the result is going to be constant anyway, but will not work in a
|
||||
* runtime context because of a void expression where a value is
|
||||
* expected. Thus, both gcc and clang will fail to compile if you use
|
||||
* the wrong macro (even if the error may seem a bit cryptic).
|
||||
*
|
||||
* Note that neither form is usable as an #if condition; if you truly
|
||||
* need to write conditional code that depends on a minimum or maximum
|
||||
* determined by the pre-processor instead of the compiler, you'll
|
||||
* have to open-code it.
|
||||
*/
|
||||
#undef MIN
|
||||
#define MIN(a, b) \
|
||||
({ \
|
||||
typeof(1 ? (a) : (b)) _a = (a), _b = (b); \
|
||||
_a < _b ? _a : _b; \
|
||||
})
|
||||
#define MIN_CONST(a, b) \
|
||||
__builtin_choose_expr( \
|
||||
__builtin_constant_p(a) && __builtin_constant_p(b), \
|
||||
(a) < (b) ? (a) : (b), \
|
||||
((void)0))
|
||||
#undef MAX
|
||||
#define MAX(a, b) \
|
||||
({ \
|
||||
typeof(1 ? (a) : (b)) _a = (a), _b = (b); \
|
||||
_a > _b ? _a : _b; \
|
||||
})
|
||||
#define MAX_CONST(a, b) \
|
||||
__builtin_choose_expr( \
|
||||
__builtin_constant_p(a) && __builtin_constant_p(b), \
|
||||
(a) > (b) ? (a) : (b), \
|
||||
((void)0))
|
||||
|
||||
/* Minimum function that returns zero only iff both values are zero.
|
||||
* Intended for use with unsigned values only. */
|
||||
/*
|
||||
* Minimum function that returns zero only if both values are zero.
|
||||
* Intended for use with unsigned values only.
|
||||
*/
|
||||
#ifndef MIN_NON_ZERO
|
||||
#define MIN_NON_ZERO(a, b) ((a) == 0 ? (b) : \
|
||||
((b) == 0 ? (a) : (MIN(a, b))))
|
||||
#define MIN_NON_ZERO(a, b) \
|
||||
({ \
|
||||
typeof(1 ? (a) : (b)) _a = (a), _b = (b); \
|
||||
_a == 0 ? _b : (_b == 0 || _b > _a) ? _a : _b; \
|
||||
})
|
||||
#endif
|
||||
|
||||
/* Round number down to multiple */
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue