bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "localename" functions suggest pure/const attribute


From: Pádraig Brady
Subject: Re: "localename" functions suggest pure/const attribute
Date: Thu, 10 Jul 2014 17:20:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 07/10/2014 01:39 AM, Assaf Gordon wrote:
> Follow-up:
> 
> On 07/09/2014 08:29 PM, Assaf Gordon wrote:
>>
>> Relating to a coreutil patch I previously sent, I'm using gnulib's 
>> "localename" module.
>> Compiling it triggers two warnings (and errors with -Werror) about functions 
>> being candidates for pure/const attributes.
>> I couldn't trigger it directly with gnulib, but it's reproducible with 
>> "coreutils":
>>
> 
> To reproduce with gnulib, try the following:
> ====
> # start tests as usual - they will succeed (or fail, but unrelated to this 
> issue)
> $ ./gnulib-tool --test localename
> 
> # manually go into the test directory, and re-compile with the warning flags
> $ cd testdir*/build
> $ find -name "*.o" -delete
> $ make CFLAGS="-O1 -g -Werror -Wsuggest-attribute=const 
> -Wsuggest-attribute=pure"
> 
> make  all-recursive
> make[1]: Entering directory `/home/gordon/projects/gnulib/testdir30793/build'
> Making all in gllib
> make[2]: Entering directory 
> `/home/gordon/projects/gnulib/testdir30793/build/gllib'
> make  all-recursive
> make[3]: Entering directory 
> `/home/gordon/projects/gnulib/testdir30793/build/gllib'
> make[4]: Entering directory 
> `/home/gordon/projects/gnulib/testdir30793/build/gllib'
> depbase=`echo localename.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
>     gcc -Wall -DHAVE_CONFIG_H -I. -I../../gllib -I..  
> -DGNULIB_STRICT_CHECKING=1   -O1 -g -Werror -Wsuggest-attribute=const 
> -Wsuggest-attribute=pure -MT localename.o -MD -MP -MF $depbase.Tpo -c -o 
> localename.o ../../gllib/localename.c &&\
>     mv -f $depbase.Tpo $depbase.Po
> ../../gllib/localename.c: In function ‘string_hash’:
> ../../gllib/localename.c:2519:1: error: function might be candidate for 
> attribute ‘pure’ if it is known to return normally 
> [-Werror=suggest-attribute=pure]
>  string_hash (const void *x)
>  ^
> cc1: all warnings being treated as errors
> make[4]: *** [localename.o] Error 1
> make[4]: Leaving directory 
> `/home/gordon/projects/gnulib/testdir30793/build/gllib'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory 
> `/home/gordon/projects/gnulib/testdir30793/build/gllib'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory 
> `/home/gordon/projects/gnulib/testdir30793/build/gllib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/gordon/projects/gnulib/testdir30793/build'
> make: *** [all] Error 2
> 
> =====
> 
> (Enabling the warnings with "gnulib-tool" prevents the test framework from 
> bootstrapping in the first place).

Rather than worry about warnings like test for gnulib tests,
coreutils configure.ac ignores those using:

  # For gnulib-tests, the set is slightly smaller still.
  nw=
  nw="$nw -Wstrict-prototypes"
  # It's not worth being this picky about test programs.
  nw="$nw -Wsuggest-attribute=const"
  nw="$nw -Wsuggest-attribute=pure"
  gl_MANYWARN_COMPLEMENT([GNULIB_TEST_WARN_CFLAGS],
                         [$GNULIB_WARN_CFLAGS], [$nw])
  AC_SUBST([GNULIB_TEST_WARN_CFLAGS])

I wonder why it's reproducible by default with coreutils for you?
Note if modifying CFLAGS, it's usually better to specify AM_CFLAGS
rather than impacting on generated CFLAGS.

Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]