On 1/20/21 10:25 AM, Albert Chin wrote:
Unfortunately, on HP-UX 11.23/IA, UINT_LEAST8_MAX evaluates to ((unsigned char)(255))
That is a known bug in HP-UX 11.23 that Gnulib has had a workaround for since 2009. See:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=3a4f1890986aeea9906c261c146bfaab4136a263 I suppose Bison cannot assume that Gnulib is in use, unfortunately. Does the attached Bison patch fix the problem for you?
From f73f899a1b16f8cd0bde64bef877491b432aa367 Mon Sep 17 00:00:00 2001 From: Paul Eggert <[email protected]> Date: Wed, 20 Jan 2021 18:30:16 -0800 Subject: [PATCH] c: port to HP-UX 11.23 Problem reported by Albert Chin in: https://lists.gnu.org/r/bug-bison/2021-01/msg00029.html * data/skeletons/c.m4 (b4_c99_int_type_define): Work around HP-UX bug. --- data/skeletons/c.m4 | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/data/skeletons/c.m4 b/data/skeletons/c.m4 index fccd4cc8..f2abec5a 100644 --- a/data/skeletons/c.m4 +++ b/data/skeletons/c.m4 @@ -254,6 +254,18 @@ typedef int_least16_t yytype_int16; typedef short yytype_int16; #endif +/* Work around bug in HP-UX 11.23, which defines these macros + incorrectly for preprocessor constants. This workaround can likely + be removed in 2023, as HPE has promised support for HP-UX 11.23 + (aka HP-UX 11i v2) only through the end of 2022; see Table 2 of + <https://h20195.www2.hpe.com/V2/getpdf.aspx/4AA4-7673ENW.pdf>. */ +#ifdef __hpux +# undef UINT_LEAST8_MAX +# undef UINT_LEAST16_MAX +# define UINT_LEAST8_MAX 255 +# define UINT_LEAST16_MAX 65535 +#endif + #if defined __UINT_LEAST8_MAX__ && __UINT_LEAST8_MAX__ <= __INT_MAX__ typedef __UINT_LEAST8_TYPE__ yytype_uint8; #elif (!defined __UINT_LEAST8_MAX__ && defined YY_STDINT_H \ -- 2.27.0
