On Mon, 21 Mar 2016, Jessica Yu wrote: > Yes, this is a concern and I'm not sure what the best way to fix it > is. If both MODULE_NAME_LEN and KSYM_NAME_LEN were straight up > constants, then I think Josh's stringify approach would have worked > perfectly. However since MODULE_NAME_LEN translates to an expression > (64 - sizeof(unsigned long)), which the preprocessor cannot evaluate, > we will need another approach. Building the format strings at run time > might be messier than we'd like. Alternatively we could just go the > simple route and simply be a bit more aggressive on the upper bound > for the format width; though the size of long varies on different > architectures, afaik the max size it could ever be on any arch is 8 > bytes, so perhaps 64 - 8 = 56 (then - 1 to make room for \0) might be > an appropriate field width. This would deserve a comment as well. So how about actually modifying MAX_PARAM_PREFIX_LEN so that it's actually properly evaluable at preprocessing time, i.e. something along the lines of diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h index 52666d9..954dae9 100644 --- a/include/linux/moduleparam.h +++ b/include/linux/moduleparam.h @@ -14,7 +14,7 @@ #endif /* Chosen so that structs with an unsigned long line up. */ -#define MAX_PARAM_PREFIX_LEN (64 - sizeof(unsigned long)) +#define MAX_PARAM_PREFIX_LEN (64 - __SIZEOF_LONG__) #ifdef MODULE #define __MODULE_INFO(tag, name, info) \ -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
