gcc warn_unused_result attribute

r.stiltskin · 12-04-2011, 11:53 PM

According to gnu online docs, gcc's default behavior should be to issue a warning when a program ignores the return value of fscanf.

And, in fact, if I write a program that ignores fscanf's return value and compile it in CodeBlocks (using gcc), it does issue the warning:

Code:

warning: ignoring return value of ‘scanf’, declared with attribute warn_unused_result

But if I compile the same program by calling gcc on the command line or in Geany, it doesn't issue any warning (even with -Wall -Wextra -pedantic, although those shouldn't matter for this anyway). I shouldn't have to specify any particular flag to get this warning -- it should be the compiler's default behavior.

What could be causing the error message to be suppressed?

(This is in Ubuntu 10.04, with gcc 4.4.3)

jhwilliams · 12-05-2011, 03:10 AM

I don't know what codeblocks or Geany are. However, I'd guess they have different library headers.

On my system (ubuntu oneiric) scanf* and friends are not marked with warn_unused_result. realloc(), however, is. When I use realloc in code without checking the return value, the compiler does generate a warning:

Code:

extern void *realloc __MALLOC_P ((void *__ptr, size_t __size))
       __attribute_warn_unused_result__;

In short, don't expect the warning unless the declaration has that attribute set.

neonsignal · 12-05-2011, 03:15 AM

The unused result warning is the default, but only applies if the attribute warn_unused_result is used in the declaration of the function.

r.stiltskin · 12-05-2011, 04:32 PM

CodeBlocks and Geany are just IDEs. They use the system headers, don't have their own.

Here's what I have found:

I was under the impression that the _warn_unused_result_ was in these function definitions by default, because of what I read in http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html, but apparently that only applies to gcc 4.5 and later.

If I finally understand it correctly, in my gcc (4.4.3-4ubuntu5) scanf, fscanf, etc., sometimes include that attribute. For example, fscanf is defined as:

Code:

extern int fscanf (FILE *__restrict __stream,
		   __const char *__restrict __format, ...) __wur;

Notice the "wur" at the end. That's #defined in /sys/cdefs.h:

Code:

# if __USE_FORTIFY_LEVEL > 0
#  define __wur __attribute_warn_unused_result__
# endif
#else
# define __attribute_warn_unused_result__ /* empty */
#endif
#ifndef __wur
# define __wur /* Ignore */
#endif

I don't know what "FORTIFY_LEVEL" means, but apparently it's connected with compiler optimization, because I found that if I compile with the command:
gcc -O myprog.cc
(that's uppercase letter O)
it gives me the "warning: ignoring return value ..." when appropriate.

The warning flags Wall, Wextra, pedantic, etc, have no effect on this warning. Only the optimization flags O, O1, O2 ...

neonsignal · 12-05-2011, 05:11 PM

The definition _FORTIFY_SOURCE will put in place some compile time checks (such as static buffer overflows and the like). This is only used to set the __USE_FORTIFY_LEVEL if there is some level of optimization also enabled.

r.stiltskin · 12-05-2011, 08:34 PM

OK, and when _FORTIFY_SOURCE is defined and is > 0, __USE_FORTIFY_LEVEL is set to 1 or 2, and the __wur in the definitions of functions such as fscanf is replaced with __attribute_warn_unused_result__

The value of __USE_FORTIFY_LEVEL is set in features.h based on the value of _FORTIFY_SOURCE.

_FORTIFY_SOURCE must be defined someplace in gcc's optimization code since it's clear that using the optimization flag invokes those warnings.

neonsignal · 12-05-2011, 09:24 PM

Quote:

_FORTIFY_SOURCE must be defined someplace in gcc's optimization code since it's clear that using the optimization flag invokes those warnings.

More likely it is configured in a file somewhere. On my system (Debian squeeze, gcc 4.4.5) it is not defined by default; I have to both define it and turn on optimization in order to trigger the fscanf warning. It sounds like the Ubuntu gcc has _FORTIFY_SOURCE turned on by default.

r.stiltskin · 12-06-2011, 12:24 AM

Well, grep doesn't find any #define for _FORTIFY_SOURCE anyplace in /usr/include or in /usr/lib/gcc, just this if statement in features.h

Code:

#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0 \
    && __GNUC_PREREQ (4, 1) && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
# if _FORTIFY_SOURCE > 1
#  define __USE_FORTIFY_LEVEL 2
# else
#  define __USE_FORTIFY_LEVEL 1
# endif
#else
# define __USE_FORTIFY_LEVEL 0
#endif

that's why I concluded that the #define is probably compiled into one of the gcc executables.

I just looked at the gcc 4.3 headers in my Debian Lenny box & they have the same directives about __wur and __USE_FORTIFY_LEVEL and _FORTIFY_SOURCE in the headers, but on that one compiling with an optimization flag doesn't turn on the ignoring-result warning, so apparently there it's not built into the compiler code, and I guess the same goes for your Squeeze.

jhwilliams · 12-06-2011, 12:40 AM

Quote:

Originally Posted by neonsignal

It sounds like the Ubuntu gcc has _FORTIFY_SOURCE turned on by default.

Indeed! gcc(1), under "Options that Control Optimization":

Code:

           NOTE: In Ubuntu 8.10 and later versions, -D_FORTIFY_SOURCE=2 is set
           by default, and is activated when -O is set to 2 or higher.  This
           enables additional compile-time and run-time checks for several
           libc functions.  To disable, specify either -U_FORTIFY_SOURCE or
           -D_FORTIFY_SOURCE=0.