Re: [sr #111072] "[[]] attributes are a C23 extension warning" with clang

[Paul J. Lucas]

On Jun 8, 2024, at 2:46 PM, Paul J. Lucas  wrote:

> #  if defined __clang__ || __cplusplus /* ||, not && */

That should have read:

#  if defined __clang__ || defined __cplusplus

- Paul

Re: [sr #111072] "[[]] attributes are a C23 extension warning" with clang

[Paul J. Lucas]

On Jun 8, 2024, at 12:38 PM, Paul Eggert  wrote:

> (Moving this from  to 
>  because it's Gnulib, not Autoconf.]

Wait a minute: at the top of the generated config.h (which is where 
_GL_ATTRIBUTE_NODISCARD is defined), it says:

/* src/config.h.  Generated from config.h.in by configure.  */
/* src/config.h.in.  Generated from configure.ac by autoheader.  */

And autoheader is part of autoconf — so why is this a GnuLib problem?

- Paul

Re: [sr #111072] "[[]] attributes are a C23 extension warning" with clang

[Paul J. Lucas]

On Jun 8, 2024, at 2:23 PM, Bruno Haible  wrote:

> Adding to what Paul Eggert wrote:
>> It looks like -Wc23-extensions is the problem. If you stop using it (or 
>> if you also use -std=gnu23), you shouldn't get those warnings. At least, 
>> that's the behavior I see with clang 18.1.6 (a bit later than your 
>> clang) on Fedora.
>> 
>> -Wc23-extensions is more trouble than it's worth when programs (as is 
>> commonly the case) use C23 extensions only when available.
> 
> You chose to desire warnings for C language constructs that are not
> yet contained in C 23. You got such warnings.

True, but _my_ code uses no such constructs.  My code is strict C11 (no 
extensions), not C23.  My code uses only NODISCARD from Gnulib’s attribute.h:

// attribute.h
#define NODISCARD _GL_ATTRIBUTE_NODISCARD

I did not define _GL_ATTRIBUTE_NODISCARD to use [[.  It’s defined in config.h 
that’s generated by configure.  IMHO, the code generated for config.h should 
not use [[ anywhere unless it knows for certain (via #if’s or other means) that 
the compiler supports [[ without warnings under any circumstances.

That aside, as I mentioned previously, this generated line:

#  if defined __clang__ && defined __cplusplus

seems wrong to me.  Because __cplusplus is not defined, that #if fails which 
causes _GL_ATTRIBUTE_NODISCARD to be defined to use [[.

IMHO, that line should be just:

#  if defined __clang__

or perhaps:

#  if defined __clang__ || __cplusplus /* ||, not && */

Indeed, the comment for the similarly defined _GL_ATTRIBUTE_MAYBE_UNUSED says:

/* In C++ and C23, this is spelled [[__maybe_unused__]].
   GCC's syntax is __attribute__ ((__unused__)).
   clang supports both syntaxes.  Except that with clang ≥ 6, < 10, in C++ mode,
   __has_c_attribute (__maybe_unused__) yields true but the use of
   [[__maybe_unused__]] nevertheless produces a warning.  */

Note that is says "In C++ and C23” which actually means “in _any_ C++ or C23” — 
that is “or” instead of “and” since a given program is either C _or_ C++ — and 
this seems to support my suggestion of changing “&& __cplusplus” to “|| 
__cplusplus”.

> But you can deactivate Gnulib's definition of _GL_ATTRIBUTE_NODISCARD
> by adding "-D_GL_ATTRIBUTE_NODISCARD=" to the CPPFLAGS or CFLAGS of your
> compilation.

But I _want_ it to figure out what D_GL_ATTRIBUTE_NODISCARD should expand into 
for me — which is the point of using that macro (via NODISCARD) in the first 
place.  I don’t want to define it myself.

- Paul

Re: [sr #111072] "[[]] attributes are a C23 extension warning" with clang

[Paul J. Lucas]

On Jun 8, 2024, at 12:38 PM, Paul Eggert  wrote:

> (Moving this from  to 
>  because it's Gnulib, not Autoconf.]

Sorry.

>> Recently, I started getting warnings like:
>> ./slist.h:170:1: warning: [[]] attributes are a C23 extension
>> [-Wc23-extensions]
>>   170 | NODISCARD
>>   | ^
>> ../lib/attribute.h:143:19: note: expanded from macro 'NODISCARD'
>>   143 | #define NODISCARD _GL_ATTRIBUTE_NODISCARD
>>   |   ^
>> ./config.h:1392:37: note: expanded from macro '_GL_ATTRIBUTE_NODISCARD'
>>  1392 | #define _GL_ATTRIBUTE_NODISCARD [[__nodiscard__]]
>>   | ^
> 
> It looks like -Wc23-extensions is the problem. If you stop using it (or if 
> you also use -std=gnu23), you shouldn't get those warnings. At least, that's 
> the behavior I see with clang 18.1.6 (a bit later than your clang) on Fedora.

FYI, I’m not using that option.  The options I am using are:

-DHAVE_CONFIG_H
-D_THREAD_SAFE
-D_ISOC11_SOURCE
-Wall
-Wcast-align
-Wcast-function-type
-Wcomma
-Wconditional-type-mismatch
-Wconditional-uninitialized
-Wconversion
-Wduplicate-enum
-Wembedded-directive
-Wenum-enum-conversion
-Wenum-float-conversion
-Wextra
-Wfloat-equal
-Wfor-loop-analysis
-Wformat-nonliteral
-Wformat-type-confusion
-Wformat=2
-Widiomatic-parentheses
-Wimplicit-fallthrough
-Wlogical-op-parentheses
-Wmisleading-indentation
-Wnewline-eof
-Wpedantic
-Wredundant-decls
-Wshadow
-Wshift-sign-overflow
-Wshorten-64-to-32
-Wsign-compare
-Wsign-conversion
-Wsometimes-uninitialized
-Wstring-conversion
-Wtautological-compare
-Wtautological-type-limit-compare
-Wundef
-Wuninitialized
-Wunreachable-code-break
-Wunreachable-code-return
-Wunreachable-code
-Wunused
-Wwrite-strings
-Wzero-as-null-pointer-constant

- Paul

Re: #if !_GL_CONFIG_H_INCLUDED breaks flex generated lexers, FYI

[Paul J. Lucas]

On Apr 13, 2023, at 10:57 AM, Bruno Haible  wrote:

>> IMHO, this is a problem with Flex, not GnuLib.  Flex should have a mechanism
>> to insert code at the top of the generated lexer like Bison’s "%code top”
>> directive.
> 
> As far as I know, it already has.
> https://westes.github.io/flex/manual/Definitions-Section.html

I totally missed that.  Sorry.

- Paul

#if !_GL_CONFIG_H_INCLUDED breaks flex generated lexers, FYI

[Paul J. Lucas]

Hello -

This recent commit:

https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=8ad7bc671475d3291df10a1a1d64fddfd30e5175

renders Flex generated lexers uncompilable. If you use GnuLib, you're using 
wrappers around standard headers like stdio.h. The recent commit added lines to 
such wrappers like this:

#if !_GL_CONFIG_H_INCLUDED
 #error "Please include config.h first."
#endif

The problem is a Flex-generated lexer's .c file has:

/* begin standard C headers. */
#include 
#include 
#include 
#include 

generated near the top and the project's include path is set to pick up the 
wrapper headers first — and the lexer's .c file doesn't have:

#include "config.h"

before the include of the wrapper headers, so it complains.

IMHO, this is a problem with Flex, not GnuLib.  Flex should have a mechanism to 
insert code at the top of the generated lexer like Bison’s "%code top” 
directive.

So this is just an FYI that the aforementioned commit can break machine 
generated C code.

- Paul

getopt.c warnings patch

[Paul J. Lucas]

The getopt.c file generates the following warnings from Apple’s gcc (Apple 
clang version 11.0.3 (clang-1103.0.32.62)):


getopt.c:208:21: warning: implicit conversion changes signedness: 'long' to
  'size_t' (aka 'unsigned long') [-Wsign-conversion]
  namelen = nameend - d->__nextchar;
  ~ ^~~
getopt.c:255:34: warning: implicit conversion changes signedness: 'int' to
  'unsigned long' [-Wsign-conversion]
else if ((ambig_set = malloc (n_options)) == NULL)
  ~~  ^
getopt.c:369:16: warning: variable 'option_index' may be uninitialized when used
  here [-Wconditional-uninitialized]
*longind = option_index;
   ^~~~
getopt.c:204:19: note: initialize the variable 'option_index' to silence this
  warning
  int option_index;
  ^
   = 0
3 warnings generated.


when compiled with these warnings enabled:

-Wall -Wcast-align -Wcomma -Wconditional-type-mismatch 
-Wconditional-uninitialized -Wconversion -Wextra -Wfloat-equal 
-Wfor-loop-analysis -Widiomatic-parentheses -Wimplicit-fallthrough 
-Wlogical-op-parentheses -Wnewline-eof -Wno-unknown-warning-option 
-Wredundant-decls -Wshadow -Wshift-sign-overflow -Wsign-compare 
-Wsign-conversion -Wsometimes-uninitialized -Wstring-conversion -Wuninitialized 
-Wunreachable-code-break -Wunreachable-code -Wunused -Wwrite-strings

Below is a patch that fixes all these warnings.

- Paul


--- lib/getopt.c.ORIG   2020-05-27 14:45:22.0 -0700
+++ lib/getopt.c2020-05-27 14:57:42.0 -0700
@@ -201,11 +201,11 @@
   const struct option *p;
   const struct option *pfound = NULL;
   int n_options;
-  int option_index;
+  int option_index = 0;
 
   for (nameend = d->__nextchar; *nameend && *nameend != '='; nameend++)
 /* Do nothing.  */ ;
-  namelen = nameend - d->__nextchar;
+  namelen = (size_t)(nameend - d->__nextchar);
 
   /* First look for an exact match, counting the options as a side
  effect.  */
@@ -252,7 +252,7 @@
  {
if (__libc_use_alloca (n_options))
  ambig_set = alloca (n_options);
-   else if ((ambig_set = malloc (n_options)) == NULL)
+   else if ((ambig_set = malloc ((size_t)n_options)) == 
NULL)
  /* Fall back to simpler error message.  */
  ambig_fallback = 1;
else

Re: Recent change to fnmatch breaks my build

[Paul J. Lucas]

After I sent this, I saw another thread about the same topic. That thread 
requested stuff from config.status:

$ grep FNMATCH config.status
S["GL_GENERATE_FNMATCH_H_FALSE"]=""
S["GL_GENERATE_FNMATCH_H_TRUE"]="#"
S["FNMATCH_H"]=""
S["HAVE_FNMATCH_H"]="1"
S["NEXT_AS_FIRST_DIRECTIVE_FNMATCH_H"]=""
S["NEXT_FNMATCH_H"]=""
S["REPLACE_FNMATCH"]="1"
S["HAVE_FNMATCH"]="1"
S["GNULIB_FNMATCH"]="1"
D["HAVE_FNMATCH_H"]=" 1"
D["HAVE_FNMATCH_H"]=" 1"
D["HAVE_FNMATCH"]=" 1"
D["GNULIB_TEST_FNMATCH"]=" 1"

In config.log, it checks for fnmatch.h and finds it, but it doesn’t have the 
aforementioned symbol.

One should be able to specify that one wants to use the Gnulib version of 
fnmatch regardless of what’s on the system.

- Paul

> On Aug 12, 2018, at 8:23 PM, Paul J. Lucas  wrote:
> 
> Hello -
> 
> I’ve been using the fnmatch module in Gnulib for a while.  I recently updated 
> Gnulib and tried to build and get:
> 
>> gcc -DHAVE_CONFIG_H -I. -I../src -g -O2  -Wall -Wcast-align -Wextra 
>> -Wredundant-decls -Wwrite-strings -MT fnmatch.o -MD -MP -MF 
>> .deps/fnmatch.Tpo -c -o fnmatch.o fnmatch.c
>> In file included from fnmatch.c:176:
>> ./fnmatch_loop.c:49:41: error: use of undeclared identifier 'FNM_EXTMATCH'
>>  if (__builtin_expect (flags & FNM_EXTMATCH, 0) && *p == '(')
>>^
> 
> In my project’s lib, there are the files:
> 
>fnmatch.c
>fnmatch.in.h
>    fnmatch_loop.c
> 
> The fnmatch.h file (that contains the FNM_EXTMATCH symbol) never gets built.
> 
> I noticed this recent change to the fnmatch module:
> 
>http://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00032.html
> 
> that seems to have broken the build for me.
> 
> For reference, my project is here:
> 
>https://github.com/paul-j-lucas/wrap
> 
> In my configure.ac, I have:
> 
>AC_CHECK_HEADERS([fnmatch.h])
># …
>AC_FUNC_FNMATCH
> 
> - Paul
> 

Recent change to fnmatch breaks my build

[Paul J. Lucas]

Hello -

I’ve been using the fnmatch module in Gnulib for a while.  I recently updated 
Gnulib and tried to build and get:

> gcc -DHAVE_CONFIG_H -I. -I../src -g -O2  -Wall -Wcast-align -Wextra 
> -Wredundant-decls -Wwrite-strings -MT fnmatch.o -MD -MP -MF .deps/fnmatch.Tpo 
> -c -o fnmatch.o fnmatch.c
> In file included from fnmatch.c:176:
> ./fnmatch_loop.c:49:41: error: use of undeclared identifier 'FNM_EXTMATCH'
>   if (__builtin_expect (flags & FNM_EXTMATCH, 0) && *p == '(')
> ^

In my project’s lib, there are the files:

fnmatch.c
fnmatch.in.h
fnmatch_loop.c

The fnmatch.h file (that contains the FNM_EXTMATCH symbol) never gets built.

I noticed this recent change to the fnmatch module:

http://lists.gnu.org/archive/html/bug-gnulib/2018-08/msg00032.html

that seems to have broken the build for me.

For reference, my project is here:

    https://github.com/paul-j-lucas/wrap

In my configure.ac, I have:

AC_CHECK_HEADERS([fnmatch.h])
# …
AC_FUNC_FNMATCH

- Paul