Re: [PATCH] file-has-acl: avoid warning from bleeding-edge GCC

On Sun, May 28, 2023 at 10:44 AM Bruno Haible wrote: > How about adding -Wno-suggest-attribute to the list of warning options that > are part of the GL_CFLAG_GNULIB_WARNINGS variable, no that such warnings > function might be candidate for attribute 'pure' > or > function might be candidate fo

Re: [PATCH] file-has-acl: avoid warning from bleeding-edge GCC

On Sun, May 28, 2023 at 10:08 AM Bruno Haible wrote: > > Hi Jim, > > Jim Meyering wrote: > > FYI, just pushed, to avoid this: > > > > lib/file-has-acl.c: In function 'have_xattr': > > lib/file-has-acl.c:54:1: error: function might be candidate for attribute > > 'pure' if it is known to return

Re: [PATCH] file-has-acl: avoid warning from bleeding-edge GCC

How about adding -Wno-suggest-attribute to the list of warning options that are part of the GL_CFLAG_GNULIB_WARNINGS variable, no that such warnings function might be candidate for attribute 'pure' or function might be candidate for attribute 'const' no longer occur in gnulib source files, comp

warnings, manywarnings: Assume autoconf >= 2.64

Gnulib assumes autoconf >= 2.64 since August 2000. Autoconf 2.64 added the macro AS_VAR_APPEND [1]. Thus, the gl_AS_VAR_APPEND macro, that is an alias of AS_VAR_APPEND, is no longer needed. Other packages than gnulib don't use this macro. [2] Therefore I'm applying this simplification. [1] https

Re: [PATCH] file-has-acl: avoid warning from bleeding-edge GCC

Hi Jim, Jim Meyering wrote: > FYI, just pushed, to avoid this: > > lib/file-has-acl.c: In function 'have_xattr': > lib/file-has-acl.c:54:1: error: function might be candidate for attribute > 'pure' if it is known to return normally [-Werror=suggest-attribute=pure] > 54 | have_xattr (cha

[PATCH] file-has-acl: avoid warning from bleeding-edge GCC

FYI, just pushed, to avoid this: lib/file-has-acl.c: In function 'have_xattr': lib/file-has-acl.c:54:1: error: function might be candidate for attribute 'pure' if it is known to return normally [-Werror=suggest-attribute=pure] 54 | have_xattr (char const *attr, char const *listbuf, ssize

Re: error: Support the compiler's control flow analysis better

Pádraig Brady wrote: > >> We might need to cast STATUS to bool to avoid the > >> following failure from coreutils CI: What you call a failure is in fact a warning. Adding -Werror is your responsibility. > >> In file included from src/die.h:22, > >> from src/chroot.c:27: > >> s

Re: error: Support the compiler's control flow analysis better (was: copy-file: Silence gcc warnings)

On 28/05/2023 13:50, Pádraig Brady wrote: On 28/05/2023 13:31, Pádraig Brady wrote: On 27/05/2023 21:53, Bruno Haible wrote: +# ifndef _GL_NO_INLINE_ERROR +# undef error +# define error(status, ...) \ + ((rpl_error)(0, __VA_ARGS__), (status) ? exit (status) : (void)0) +# endif We might

Re: error: Support the compiler's control flow analysis better (was: copy-file: Silence gcc warnings)

On 28/05/2023 13:31, Pádraig Brady wrote: On 27/05/2023 21:53, Bruno Haible wrote: +# ifndef _GL_NO_INLINE_ERROR +# undef error +# define error(status, ...) \ + ((rpl_error)(0, __VA_ARGS__), (status) ? exit (status) : (void)0) +# endif We might need to cast STATUS to bool to avoid the fo

Re: error: Support the compiler's control flow analysis better (was: copy-file: Silence gcc warnings)

On 27/05/2023 21:53, Bruno Haible wrote: Paul Eggert wrote: Maybe by defining error and error_at_line as inline functions They're defined by glibc, no? The definitions might collide. Yes, they are defined in glibc. Overriding functions without causing collisions is our core expertise here :)