On 2014/4/28 22:23, Petr Tesarik wrote: > On Sat, 26 Apr 2014 12:07:06 +0800 > Wang Nan <wangnan0 at huawei.com> wrote: > >> From: Wang Nan <pi3orama at gmail.com> >> >> According to C standard, numerical limitations macros such as ULONG_MAX >> should be defined in <limits.h>, and must be defined as "constant >> expressions suitable for use in #if preprocessing directives." (see >> "Numerical limits" section in the standard). >> >> Original definition in common.h breaks this rule: >> >> #define LONG_MAX ((long)(~0UL>>1)) >> >> which causes macros like following failure: >> >> #if LONG_MAX == 2147483647 >> # define LONG_BIT 32 >> #else >> # define LONG_BIT 64 >> #endif >> >> Unfortunately, the above code piece is taken from real glibc header >> (/usr/include/bits/xopen_lim.h), which is happen to be included by >> <limits.h> if _GNU_SOURCE is defined. >> >> This patch include <limits.h> in common.h to use C standard numerical >> macros. For system without such macros defined by C, this patch also >> defines L(L)ONG_MAX in a standard compatible way. By checking wich >> >> gcc -dM -E - <<<'' >> >> we know that __LONG_MAX__ and __LLONG_MAX__ macros should be defined by >> gcc by default. Definition of ULONG_MAX and ULLONG_MAX are taken from >> gcc standard include file (include-fixed/limits.h). >> >> In addition, macro ULONGLONG_MAX is nonstandard, the standard way for >> defining max ulonglong is ULLONG_MAX. >> >> Signed-off-by: Wang Nan <wangnan0 at huawei.com> >> Cc: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> >> Cc: Petr Tesarik <ptesarik at suse.cz> >> Cc: kexec at lists.infradead.org >> Cc: Geng Hui <hui.geng at huawei.com> >> Cc: Liu Hua <sdu.liu at huawei.com> >> >> --- >> common.h | 18 +++++++++++++++--- >> 1 file changed, 15 insertions(+), 3 deletions(-) >> >> diff --git a/common.h b/common.h >> index 6ad3ca7..124f107 100644 >> --- a/common.h >> +++ b/common.h >> @@ -16,17 +16,29 @@ >> #ifndef _COMMON_H >> #define _COMMON_H >> >> +#include <limits.h> >> + >> #define TRUE (1) >> #define FALSE (0) >> #define ERROR (-1) >> >> #ifndef LONG_MAX >> -#define LONG_MAX ((long)(~0UL>>1)) >> +# warning LONG_MAX should have been defined in <limits.h> >> +# define LONG_MAX __LONG_MAX__ >> #endif >> #ifndef ULONG_MAX >> -#define ULONG_MAX (~0UL) >> +# warning ULONG_MAX should have been defined in <limits.h> >> +# define ULONG_MAX (LONG_MAX * 2UL + 1UL) >> +#endif >> +#ifndef LLONG_MAX >> +# warning LLONG_MAX should have been defined in <limits.h> >> +# define LLONG_MAX __LONG_LONG_MAX__ >> +#endif >> +#ifndef ULLONG_MAX >> +# warning ULLONG_MAX should have been defined in <limits.h> >> +# define ULLONG_MAX (LLONG_MAX * 2ULL + 1ULL) >> #endif >> -#define ULONGLONG_MAX (~0ULL) >> +#define ULONGLONG_MAX ULLONG_MAX > > Hi Wang Nan, > > is this actually needed on some known platform? If not, then I'd rather > remove all these #ifndef stanzas and rely on <limits.h>. I mean, if you > can't rely on standard C constants, then why should be the gcc-specific > pre-defined macros (__LONG_MAX__ et al.) available? > These macros exist at the first version (at makedumpfile.h), an enforced by commit ab9c60bf (just because they conflict with limits.h ...). But I don't think there exists a real platform without <limits.h>. I agree with you that totally removing these macros should be better. > It's probably better to put the burden on the person doing the > port, because they should know what is appropriate for their compiler > and/or libc. > > Just my opinion, > Petr T >
