From: Paul Eggert <eggert@cs.ucla.edu>
To: bug-gnulib@gnu.org
Cc: Paul Eggert <eggert@cs.ucla.edu>
Subject: [PATCH] stdint-tests: long long preproc on recent Sun C
Date: Sun, 12 Sep 2021 23:50:53 -0700 [thread overview]
Message-ID: <20210913065053.1604865-1-eggert@cs.ucla.edu> (raw)
* tests/test-stdint.c: Test long long preprocessor constants on
Oracle Developer Studio 12.6, where they should work.
---
ChangeLog | 6 ++++++
| 6 ++++--
m4/extern-inline.m4 | 3 ++-
tests/test-func.c | 4 ++--
tests/test-stdint.c | 5 +++--
5 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f1e5cc7d6..d64252c38 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2021-09-12 Paul Eggert <eggert@cs.ucla.edu>
+
+ stdint-tests: long long preproc on recent Sun C
+ * tests/test-stdint.c: Test long long preprocessor constants on
+ Oracle Developer Studio 12.6, where they should work.
+
2021-09-13 Bruno Haible <bruno@clisp.org>
extern-inline: Fix syntax error on macOS with GCC 11 (regr. 2021-08-22).
--git a/doc/posix-headers/stdint.texi b/doc/posix-headers/stdint.texi
index 784799b0f..7f33b20d2 100644
--- a/doc/posix-headers/stdint.texi
+++ b/doc/posix-headers/stdint.texi
@@ -58,8 +58,10 @@ so public header files should avoid these types.
Macros are used instead of typedefs.
@item
Some C preprocessors mishandle constants that do not fit in @code{long int}.
-For example, as of 2007, Sun C mishandles @code{#if LLONG_MIN < 0} on
-a platform with 32-bit @code{long int} and 64-bit @code{long long int}.
+For example, as of 2007, Sun C mishandled @code{#if LLONG_MIN < 0} on
+a platform with 32-bit @code{long int} and 64-bit @code{long long int};
+this bug was fixed on or before Oracle Developer Studio 12.6
+(Sun C 5.15 SunOS_sparc 2017/05/30).
Some older preprocessors mishandle constants ending in @code{LL}.
To work around these problems, compute the value of expressions like
@code{LONG_MAX < LLONG_MAX} at @code{configure}-time rather than at
diff --git a/m4/extern-inline.m4 b/m4/extern-inline.m4
index 94443f212..a4ac5ea53 100644
--- a/m4/extern-inline.m4
+++ b/m4/extern-inline.m4
@@ -17,7 +17,8 @@ AC_DEFUN([gl_EXTERN_INLINE],
mishandles inline functions that call each other. E.g., for 'inline void f
(void) { } inline void g (void) { f (); }', c99 incorrectly complains
'reference to static identifier "f" in extern inline function'.
- This bug was observed with Sun C 5.12 SunOS_i386 2011/11/16.
+ This bug was observed with Oracle Developer Studio 12.6
+ (Sun C 5.15 SunOS_sparc 2017/05/30).
Suppress extern inline (with or without __attribute__ ((__gnu_inline__)))
on configurations that mistakenly use 'static inline' to implement
diff --git a/tests/test-func.c b/tests/test-func.c
index d68075966..0d00b97ef 100644
--- a/tests/test-func.c
+++ b/tests/test-func.c
@@ -27,8 +27,8 @@ main ()
{
ASSERT (strlen (__func__) > 0);
- /* On SunPRO C 5.9, sizeof __func__ evaluates to 0. The compiler warns:
- "warning: null dimension: sizeof()". */
+ /* On Oracle Developer Studio 12.6 and earlier, sizeof __func__ yields 0.
+ The compiler warns: "warning: null dimension: sizeof()". */
#if !defined __SUNPRO_C
ASSERT (strlen (__func__) + 1 == sizeof __func__);
#endif
diff --git a/tests/test-stdint.c b/tests/test-stdint.c
index dc6fad7aa..737ff56c8 100644
--- a/tests/test-stdint.c
+++ b/tests/test-stdint.c
@@ -247,9 +247,10 @@ uintmax_t j[2] = { UINTMAX_C (17), UINTMAX_MAX };
verify (TYPE_MAXIMUM (uintmax_t) == UINTMAX_MAX);
verify_same_types (UINTMAX_MAX, (uintmax_t) 0 + 0);
-/* As of 2007, Sun C and HP-UX 10.20 cc don't support 'long long' constants in
+/* Older Sun C and HP-UX 10.20 cc don't support 'long long' constants in
the preprocessor. */
-#if !(defined __SUNPRO_C || (defined __hpux && !defined __GNUC__))
+#if !((defined __SUNPRO_C && __SUNPRO_C < 0x5150) \
+ || (defined __hpux && !defined __GNUC__))
#if INTMAX_MIN && INTMAX_MAX && UINTMAX_MAX
/* ok */
#else
--
2.30.2
reply other threads:[~2021-09-13 6:51 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210913065053.1604865-1-eggert@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=bug-gnulib@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).