bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
* memset_explicit: Fix compilation error on some OpenSolaris derivatives
@ 2024-04-19 22:12 Bruno Haible
  2024-04-24  3:50 ` Collin Funk
  0 siblings, 1 reply; 9+ messages in thread
From: Bruno Haible @ 2024-04-19 22:12 UTC (permalink / raw
  To: bug-gnulib

Compiling a testdir for 'memset_explicit' on Solaris 11 SmartOS with clang
as compiler, I get an error:

clang -O2 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DNO_XMALLOC -DEXEEXT=\"\" -I. -I../../gllib -I..  -DGNULIB_STRICT_CHECKING=1 -I/root/prefix64clang/include -I/opt/tools/include -Wall -D_REENTRANT -fvisibility=hidden -g -O2 -MT memset_explicit.o -MD -MP -MF $depbase.Tpo -c -o memset_explicit.o ../../gllib/memset_explicit.c &&\
mv -f $depbase.Tpo $depbase.Po
../../gllib/memset_explicit.c:34:10: error: call to undeclared function 'memset_s'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
  (void) memset_s (s, len, c, len);
         ^
../../gllib/memset_explicit.c:34:10: note: did you mean 'memset'?
/usr/include/iso/string_iso.h:72:14: note: 'memset' declared here
extern void *memset(void *, int, size_t);
             ^
1 error generated.
gmake[4]: *** [Makefile:11453: memset_explicit.o] Error 1


The reason is that on this system, the function 'memset_s' exists in libc,
but is only declared (in /usr/include/iso/string_iso.h) if __EXT1_VISIBLE
is set. __EXT1_VISIBLE is defined by <sys/feature_tests.h> if
__STDC_WANT_LIB_EXT1__ is defined to non-zero at that point.
gnulib's lib/memset_explicit.c defines __STDC_WANT_LIB_EXT1__, but it comes
too late, because <config.h> has already included <stdalign.h>, <stddef.h>,
<stdbool.h>, or <assert.h>. <stdbool.h> and <assert.h> include
<sys/feature_tests.h>.

This patch fixes it.

Note that this may break programs which define errno_t and rsize_t. Such
programs will need to change, because these are now standardized types.


2024-04-19  Bruno Haible  <bruno@clisp.org>

	memset_explicit: Fix compilation error on some OpenSolaris derivatives.
	* m4/extensions.m4 (gl_USE_SYSTEM_EXTENSIONS): Arrange to define
	__STDC_WANT_LIB_EXT1__ to 1.
	* modules/memset_explicit (Depends-on): Add extensions.
	* m4/memset_explicit.m4 (gl_FUNC_MEMSET_EXPLICIT): Require
	gl_USE_SYSTEM_EXTENSIONS.
	* lib/memset_explicit.c (__STDC_WANT_LIB_EXT1__): Remove definition.

diff --git a/lib/memset_explicit.c b/lib/memset_explicit.c
index cf6cc64784..33c0987348 100644
--- a/lib/memset_explicit.c
+++ b/lib/memset_explicit.c
@@ -16,11 +16,7 @@
 
 #include <config.h>
 
-/* memset_s need this define */
-#if HAVE_MEMSET_S
-# define __STDC_WANT_LIB_EXT1__ 1
-#endif
-
+/* Specification.  */
 #include <string.h>
 
 /* Set S's bytes to C, where S has LEN bytes.  The compiler will not
diff --git a/m4/extensions.m4 b/m4/extensions.m4
index 887c651564..fae4141358 100644
--- a/m4/extensions.m4
+++ b/m4/extensions.m4
@@ -1,5 +1,5 @@
 # extensions.m4
-# serial 23  -*- Autoconf -*-
+# serial 24  -*- Autoconf -*-
 dnl Copyright (C) 2003, 2006-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -230,4 +230,10 @@ AC_DEFUN_ONCE([gl_USE_SYSTEM_EXTENSIONS]
         [Define to enable the declarations of ISO C 11 types and functions.])
       ;;
   esac
+
+  dnl On OpenSolaris derivatives, the include files contains a couple of
+  dnl declarations that are only activated with an explicit
+  dnl -D__STDC_WANT_LIB_EXT1__.
+  AC_DEFINE([__STDC_WANT_LIB_EXT1__], [1],
+    [Define to enable the declarations of ISO C 23 Annex K types and functions.])
 ])
diff --git a/m4/memset_explicit.m4 b/m4/memset_explicit.m4
index a47973ec4a..499a95968a 100644
--- a/m4/memset_explicit.m4
+++ b/m4/memset_explicit.m4
@@ -1,5 +1,5 @@
 # memset_explicit.m4
-# serial 2
+# serial 3
 dnl Copyright 2022-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -8,6 +8,8 @@
 AC_DEFUN([gl_FUNC_MEMSET_EXPLICIT],
 [
   AC_REQUIRE([gl_STRING_H_DEFAULTS])
+  dnl Persuade OpenSolaris derivatives' <string.h> to declare memset_s().
+  AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])
 
   gl_CHECK_FUNCS_ANDROID([memset_explicit], [[#include <string.h>]])
   if test $ac_cv_func_memset_explicit = no; then
diff --git a/modules/memset_explicit b/modules/memset_explicit
index da16edefd6..294c9f4d8e 100644
--- a/modules/memset_explicit
+++ b/modules/memset_explicit
@@ -7,6 +7,7 @@ m4/memset_explicit.m4
 
 Depends-on:
 string
+extensions
 
 configure.ac:
 gl_FUNC_MEMSET_EXPLICIT





^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives
  2024-04-19 22:12 memset_explicit: Fix compilation error on some OpenSolaris derivatives Bruno Haible
@ 2024-04-24  3:50 ` Collin Funk
  2024-04-24  6:22   ` Paul Eggert
  0 siblings, 1 reply; 9+ messages in thread
From: Collin Funk @ 2024-04-24  3:50 UTC (permalink / raw
  To: Bruno Haible, bug-gnulib

Hi Bruno,

On 4/19/24 3:12 PM, Bruno Haible wrote:
> The reason is that on this system, the function 'memset_s' exists in libc,
> but is only declared (in /usr/include/iso/string_iso.h) if __EXT1_VISIBLE
> is set. __EXT1_VISIBLE is defined by <sys/feature_tests.h> if
> __STDC_WANT_LIB_EXT1__ is defined to non-zero at that point.
> gnulib's lib/memset_explicit.c defines __STDC_WANT_LIB_EXT1__, but it comes
> too late, because <config.h> has already included <stdalign.h>, <stddef.h>,
> <stdbool.h>, or <assert.h>. <stdbool.h> and <assert.h> include
> <sys/feature_tests.h>.

In GNU inetutils I see the following warnings in multiple places:

In file included from telnetd.h:19,
                 from pty.c:21:
../config.h:2783:9: warning: "__STDC_WANT_LIB_EXT1__" redefined
 2783 | #define __STDC_WANT_LIB_EXT1__ 1
      |         ^~~~~~~~~~~~~~~~~~~~~~
In file included from ./telnetd.h:19,
                 from term.c:21:
../config.h:2783:9: warning: "__STDC_WANT_LIB_EXT1__" redefined
 2783 | #define __STDC_WANT_LIB_EXT1__ 1
      |         ^~~~~~~~~~~~~~~~~~~~~~

In pty.c we have:

    #include <config.h>
    #include "telnetd.h"

in telnetd.h:

     #include <config.h>
     #include <sys/types.h>
     /* Many more system headers (or gnulib versions). */

I'm a bit confused as to why I only see warnings for this macro from
gcc. Should this be wrapped in an #ifndef like the ones in
AC_USE_SYSTEM_EXTENSIONS?

Collin


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives
  2024-04-24  3:50 ` Collin Funk
@ 2024-04-24  6:22   ` Paul Eggert
  2024-04-24  6:50     ` Collin Funk
  2024-04-24 18:04     ` Bruno Haible
  0 siblings, 2 replies; 9+ messages in thread
From: Paul Eggert @ 2024-04-24  6:22 UTC (permalink / raw
  To: Collin Funk, Bruno Haible, bug-gnulib

On 2024-04-23 20:50, Collin Funk wrote:
> In pty.c we have:
> 
>      #include <config.h>
>      #include "telnetd.h"
> 
> in telnetd.h:
> 
>       #include <config.h>

Why is telnetd.h including config.h? Only a top-level C file should 
include config.h, and it should so so at the start.



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives
  2024-04-24  6:22   ` Paul Eggert
@ 2024-04-24  6:50     ` Collin Funk
  2024-04-24 13:22       ` Simon Josefsson via Gnulib discussion list
  2024-04-24 18:06       ` Bruno Haible
  2024-04-24 18:04     ` Bruno Haible
  1 sibling, 2 replies; 9+ messages in thread
From: Collin Funk @ 2024-04-24  6:50 UTC (permalink / raw
  To: Paul Eggert, Bruno Haible, bug-gnulib

Hi Paul,

On 4/23/24 11:22 PM, Paul Eggert wrote:
> Why is telnetd.h including config.h? Only a top-level C file should
> include config.h, and it should so so at the start.

I don't disagree. Most of those lines are 20 years old, so I assume it
wasn't a problem then. Though I do wonder how common those warnings
would be in other projects.

I know that warnings in test gnulib test directories can be ignored,
but just as an example:

$ env GNULIB_TOOL_IMPL=py gnulib-tool --create-testdir --dir testdir1 fstatat
$ cd testdir1
$ ./configure --enable-silent-rules
$ make 2>&1 | grep '__STDC_WANT_LIB_EXT1__' | wc -l
354

Collin


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives
  2024-04-24  6:50     ` Collin Funk
@ 2024-04-24 13:22       ` Simon Josefsson via Gnulib discussion list
  2024-04-25  1:09         ` Collin Funk
  2024-04-24 18:06       ` Bruno Haible
  1 sibling, 1 reply; 9+ messages in thread
From: Simon Josefsson via Gnulib discussion list @ 2024-04-24 13:22 UTC (permalink / raw
  To: Collin Funk; +Cc: Paul Eggert, Bruno Haible, bug-gnulib, bug-inetutils

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

Collin Funk <collin.funk1@gmail.com> writes:

> Hi Paul,
>
> On 4/23/24 11:22 PM, Paul Eggert wrote:
>> Why is telnetd.h including config.h? Only a top-level C file should
>> include config.h, and it should so so at the start.
>
> I don't disagree. Most of those lines are 20 years old, so I assume it
> wasn't a problem then. Though I do wonder how common those warnings
> would be in other projects.

I think this was fairly common before.  If there had been a 'make
syntax-check' rule for this, we would have caught it!  I have removed
use of HAVE_CONFIG_H and fixed telnetd.h in Inetutils now, thanks.

https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=32336c79b6aede7beef1d6929b631a53d141cee6
https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=c7f6910d6832d90be59033911a39de2d4b59de30

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives
  2024-04-24  6:22   ` Paul Eggert
  2024-04-24  6:50     ` Collin Funk
@ 2024-04-24 18:04     ` Bruno Haible
  1 sibling, 0 replies; 9+ messages in thread
From: Bruno Haible @ 2024-04-24 18:04 UTC (permalink / raw
  To: Collin Funk, bug-gnulib, Paul Eggert

Paul Eggert wrote:
> Why is telnetd.h including config.h? Only a top-level C file should 
> include config.h, and it should so so at the start.

We don't have a rule that config.h should *only* be included at the
start of each compilation unit. Packages can and do include <config.h>
twice.

Therefore config.h needs to be idempotent. [1]

I'm applying this fix. Thanks, Collin, for the report.

[1] https://lists.gnu.org/archive/html/bug-gnulib/2023-01/msg00207.html


2024-04-24  Bruno Haible  <bruno@clisp.org>

	Fix warnings triggered by including <config.h> twice (regr. 2024-04-19).
	Reported by Collin Funk in
	<https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00398.html>.
	* m4/extensions.m4 (gl_USE_SYSTEM_EXTENSIONS): Use AH_VERBATIM instead
	of AC_DEFINE.

diff --git a/m4/extensions.m4 b/m4/extensions.m4
index fae4141358..1fb68956b3 100644
--- a/m4/extensions.m4
+++ b/m4/extensions.m4
@@ -1,5 +1,5 @@
 # extensions.m4
-# serial 24  -*- Autoconf -*-
+# serial 25  -*- Autoconf -*-
 dnl Copyright (C) 2003, 2006-2024 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -234,6 +234,11 @@ AC_DEFUN_ONCE([gl_USE_SYSTEM_EXTENSIONS]
   dnl On OpenSolaris derivatives, the include files contains a couple of
   dnl declarations that are only activated with an explicit
   dnl -D__STDC_WANT_LIB_EXT1__.
-  AC_DEFINE([__STDC_WANT_LIB_EXT1__], [1],
-    [Define to enable the declarations of ISO C 23 Annex K types and functions.])
+  AH_VERBATIM([USE_ISO_C_23_ANNEX_K_EXTENSIONS],
+[/* Define to enable the declarations of ISO C 23 Annex K types and functions.  */
+#if !(defined __STDC_WANT_LIB_EXT1__ && __STDC_WANT_LIB_EXT1__)
+#undef/**/__STDC_WANT_LIB_EXT1__
+#define __STDC_WANT_LIB_EXT1__ 1
+#endif
+])
 ])





^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives
  2024-04-24  6:50     ` Collin Funk
  2024-04-24 13:22       ` Simon Josefsson via Gnulib discussion list
@ 2024-04-24 18:06       ` Bruno Haible
  2024-04-24 19:59         ` Collin Funk
  1 sibling, 1 reply; 9+ messages in thread
From: Bruno Haible @ 2024-04-24 18:06 UTC (permalink / raw
  To: Paul Eggert, bug-gnulib, Collin Funk

Hi Collin,

> $ env GNULIB_TOOL_IMPL=py gnulib-tool --create-testdir --dir testdir1 fstatat
> $ cd testdir1
> $ ./configure --enable-silent-rules
> $ make 2>&1 | grep '__STDC_WANT_LIB_EXT1__' | wc -l
> 354

I don't reproduce this. What are your CPPFLAGS and CFLAGS?

Bruno





^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives
  2024-04-24 18:06       ` Bruno Haible
@ 2024-04-24 19:59         ` Collin Funk
  0 siblings, 0 replies; 9+ messages in thread
From: Collin Funk @ 2024-04-24 19:59 UTC (permalink / raw
  To: Bruno Haible, Paul Eggert, bug-gnulib

On 4/24/24 11:06 AM, Bruno Haible wrote:
>> $ env GNULIB_TOOL_IMPL=py gnulib-tool --create-testdir --dir testdir1 fstatat
>> $ cd testdir1
>> $ ./configure --enable-silent-rules
>> $ make 2>&1 | grep '__STDC_WANT_LIB_EXT1__' | wc -l
>> 354
> 
> I don't reproduce this. What are your CPPFLAGS and CFLAGS?

I realized after reporting that Fedora 40 updated my gcc version to
14.0. I built gcc 13.2.0 using the tarball from the GNU FTP server and
it occurs there too. Maybe it doesn't for older versions?

$ env GNULIB_TOOL_IMPL=py gnulib-tool --create-testdir --dir testdir1 fstatat
$ cd testdir1
$ ./configure CC=gcc-13.2
$ make 2>&1 | grep '__STDC_WANT_LIB_EXT1__' | wc -l
354

$ find . -name 'Makefile' | xargs grep '^CFLAGS'
./gllib/Makefile:CFLAGS = -g -O2
./glm4/Makefile:CFLAGS = -g -O2
./gltests/Makefile:CFLAGS = -Wno-error -g -O2
./Makefile:CFLAGS = -g -O2

$ find . -name 'Makefile' | xargs grep '^CPPFLAGS'
./gllib/Makefile:CPPFLAGS = 
./glm4/Makefile:CPPFLAGS = 
./gltests/Makefile:CPPFLAGS = 
./Makefile:CPPFLAGS = 

Here is an example of the invocation that shows the warning:

gcc-13.2 -DHAVE_CONFIG_H -DEXEEXT=\"\" -I.  -DGNULIB_STRICT_CHECKING=1 -I. -I. -I.. -I./.. -I../gllib -I./../gllib   -Wno-error -g -O2 -MT test-sys_types.o -MD -MP -MF .deps/test-sys_types.Tpo -c -o test-sys_types.o test-sys_types.c

Collin


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: memset_explicit: Fix compilation error on some OpenSolaris derivatives
  2024-04-24 13:22       ` Simon Josefsson via Gnulib discussion list
@ 2024-04-25  1:09         ` Collin Funk
  0 siblings, 0 replies; 9+ messages in thread
From: Collin Funk @ 2024-04-25  1:09 UTC (permalink / raw
  To: Simon Josefsson; +Cc: Paul Eggert, Bruno Haible, bug-gnulib, bug-inetutils

Hi Simon,

On 4/24/24 6:22 AM, Simon Josefsson wrote:
> I think this was fairly common before.  If there had been a 'make
> syntax-check' rule for this, we would have caught it!  I have removed
> use of HAVE_CONFIG_H and fixed telnetd.h in Inetutils now, thanks.

Thanks! It showed up from some other files but I think those are all
*.c files including *.c files (ifconfig/system/*.c). That is the same
reason for some of the occurrences in gnulib tests too. Bruno's patch
fixed those for me, so everything should be good now.

Collin


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-04-25  1:09 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-19 22:12 memset_explicit: Fix compilation error on some OpenSolaris derivatives Bruno Haible
2024-04-24  3:50 ` Collin Funk
2024-04-24  6:22   ` Paul Eggert
2024-04-24  6:50     ` Collin Funk
2024-04-24 13:22       ` Simon Josefsson via Gnulib discussion list
2024-04-25  1:09         ` Collin Funk
2024-04-24 18:06       ` Bruno Haible
2024-04-24 19:59         ` Collin Funk
2024-04-24 18:04     ` Bruno Haible

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).