[Resending as the first message had the incorrect "bus-bison" as the
return address.]
On 1/20/21 3:50 PM, Albert Chin wrote:
Unfortunately, on HP-UX 11.23/IA, UINT_LEAST8_MAX evaluates to
((unsigned char)(255)) causing a problem with:
#elif (!defined __UINT_LEAST8_MAX__ && defined YY_STDINT_H \
&& UINT_LEAST8_MAX <= INT_MAX)
This is also an issue for UINT_LEAST16_MAX.
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 <egg...@cs.ucla.edu>
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
