GCC warning, whom to blame?

[Jakub Jelinek]

On Thu, Mar 10, 2005 at 02:33:52PM +0100, Ralf Ertzinger wrote:
> I am getting a GCC error while compiling a package (which is not part of FC),
> and I'd like to know if this is a gcc4 bug (which I think it is):
> 
> The compile dies with:
> 
> configfile.c:87:73: error: macro "read" passed 4 arguments, but takes just 3
> configfile.c: In function 'xmms_cfg_read_value':
> configfile.c:86: warning: return makes integer from pointer without a cast
> configfile.c:95:66: error: macro "read" passed 4 arguments, but takes just 3
> configfile.c: In function 'xmms_cfg_write_value':
> configfile.c:94: warning: statement with no effect
> 
> 
> The line in question reads:
> 
> 82 gboolean xmms_cfg_read_value(ConfigFile * config_file,
> 83                              const gchar * section, const gchar * key,
> 84                              XmmsCfgValueType value_type, gpointer * value)
> 85 {
> 86     return xmms_cfg_value_type_func[value_type].read(config_file,
> 87                                                      section, key, value);
> 88 }
> 
> I think glibc implemets the read system call as a macro, and GCC tries to
> apply this macro to the .read part above. Am I correct? If yes, is GCC
> correct in doing this?

This is a bug in xmms or whatever this snippet is from.
POSIX allows (the vast majority of) functions it defines to be also defined
as function-like macros.
You can either #undef read after including system headers and before you
start using it for something else, or prevent it from being expanded
as function-like macro:
> 86     return (xmms_cfg_value_type_func[value_type].read) (config_file,
> 87                                                         section, key, value);

The latter solution is preferrable, as that doesn't prevent checking of
normal read calls in the same source.

That said, we might be changing some of the -D_FORTIFY_SOURCE={1,2}
checking wrapper macros to extern inline functions, so code like this
would continue working as is (though e.g. memcpy etc. macros are more
likely to stay).  Which doesn't mean the applications shouldn't be fixed.

	Jakub