Hi Beata,
On 11-11-2022 14:45, Beata Michalska wrote:
Hi Tudor,
On Tue, Nov 08, 2022 at 04:14:10PM +0000, Tudor Cretu wrote:
Some safe functions are wrappers around functions with an optional parameter (e.g. open, openat, semctl). To access an element from an
I think those are mostly (if not all) wrappers for syscalls so I guess we could re-phrase this as: Some of the safe functions providing wrappers for commonly used syscalls allow specifying an optional parameter ......
empty va_list is undefined behaviour. Introduce the macro SAFE_WRAPPER_COND_HANDLER that handles the variadicness of such
/that handles/that takes over handling the .......
wrappers by selecting the right handler for each case.
/for each case/for whether the optional argument has been provided or not ?
The intended usage is:
#define SAFE_FN(args, ...) \ SAFE_WRAPPER_COND_HANDLER(, ##__VA_ARGS__, \ SAFE_FN_HANDLER_1, \ SAFE_FN_HANLDER_0) \ ((args), ##__VA_ARGS__)
Subsequent patches would adapt the SAFE_* macros to avoid the undefined
relevant SAFE_* ....behaviour in the safe_* functions.
the corresponding safe_* ....Signed-off-by: Tudor Cretu tudor.cretu@arm.com
include/safe_vararg_macros.h | 37 ++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 include/safe_vararg_macros.h
diff --git a/include/safe_vararg_macros.h b/include/safe_vararg_macros.h
Just wondering if it would not be better to have the file name prefixed with 'tst_', to align with ones like tst_safe_macros.h (some of the 'old' headers are already including the 'tst_*' ones so it should be good on that front)
new file mode 100644 index 000000000..cc95d2dd0 --- /dev/null +++ b/include/safe_vararg_macros.h @@ -0,0 +1,37 @@ +// SPDX-License-Identifier: GPL-2.0 -or-later +/*
- Copyright (c) 2022 Arm Ltd.
- Internal helper functions for macros that handle safe wrappers for variadic
/helper functions/helpers ?
- functions.
We are actually ending up (with this series) with variadic macros, not the functions themselves, so maybe simply 'safe variadic wrappers for corresponding safe functions' ? (same would apply to comments below)
- Do not use directly in test programs.
- */
+/*
- Some safe functions are wrappers around functions with an optional parameter
/wrappers around functions/wrappers for syscalls ?
- (e.g. open, openat, semctl). To access an element from an empty va_list is
- undefined behaviour. This macro enables handling the variadicness of such
- wrappers by selecting the right handler for each case. The intended usage is:
/for each case/depending on whether the variadic argument has been supplied or not ?
- #define SAFE_FN(args, ...) \
SAFE_WRAPPER_COND_HANDLER(, ##__VA_ARGS__, \
SAFE_FN_HANDLER_1, \
SAFE_FN_HANLDER_0) \
((args), ##__VA_ARGS__)
- Where SAFE_FN_HANDLER_0 is the handler used when the optional parameter is
- not specified and SAFE_FN_HANDLER_1 is the handler used when the optional
- parameter is specified.
SAFE_FN_HANDLER_1 is the handler used otherwise. (to reduce repeating of parameter is specified ....)
- The way it works is that SAFE_WRAPPER_COND_HANDLER returns the third
- parameter passed. If SAFE_FN is called with an element in __VA_ARGS__,
/with an element/with a variadic argument
- then SAFE_WRAPPER_COND_HANDLER just returns SAFE_FN_HANDLER_1. If SAFE_FN
- is called with an empty __VA_ARGS__, then the comma before the ‘##’ will be
- deleted and SAFE_FN_HANLDER_0 becomes the third argument. Finally, the chosen
as a consequence the macro arguments will get shifted, with SAFE_FN_HANLDER_0 becoming the actual third argument
- handler is called with the original arguments.
So the last statement refers to safe macros using the SAFE_WRAPPER_COND_HANDLER. SAFE_WRAPPER_COND_HANDLER per se is not actually dealing with the arguments, it's there only to pick the right handler.
- Note: this macro only handles len(__VA_ARGS__) <= 1.
- */
+#define SAFE_WRAPPER_COND_HANDLER(cond_empty_drop, cond_non_empty, SAFE_HELPER, ...) \
- SAFE_HELPER
The naming here suggested in the previous thread was more of a illustrative purposes really. SAFE_WRAPPER_COND_HANDLER proves to be somewhat tediously too verbose so maybe we could use SAFE_COND_HANDLER, which would help getting the formatting more ...readable (?). Furthermore, as the first argument is really only a syntax guard (to get the preceding comma for ##__VA_ARGS__ ) we could give it more meaningful name like empty or void with the second one becoming cond_arg ? How does that sound ?
Many thanks for the detailed review! The suggestions sound good! I've updated the series, feel free to further suggest improvement.
Thanks, Tudor
BR B.
-- 2.25.1
linux-morello-ltp mailing list -- linux-morello-ltp@op-lists.linaro.org To unsubscribe send an email to linux-morello-ltp-leave@op-lists.linaro.org