From: Maynard J. <may...@us...> - 2007-04-04 19:11:04
Attachments:
oprof-unused-result.patch
|
Problem: OProfile CVS fails to build when packaged as a src rpm and built using rpmbuild. The compilation error is: cc1plus: warnings being treated as errors file_manip.cpp: In function 'bool copy_file( const std::string&, const std::string&)': file_manip.cpp:52: warning: ignoring return value of 'int chown(const char*, __uid_t, __gid_t)', declared with attribute warn_unused_result This is happening on at least two recent distros I tried (SLES 10 and RHEL5) and on multiple architectures (Intel P4, IBM POWER5). Cause: The call to chown() in libutil++/file_manip.cpp does not catch the return value. A manual build of OProfile doesn't complain about this, but rpmbuild does complain because of how the optflags macro is set in the rpm build environment. Running 'rpm --eval "%{optflags}"' on the distros mentioned above shows _FORTIFY_SOURCE=2 is defined. And since chown() is declared with __attribute_warn_unused_result__ in unistd.h, the warning surfaces when FORTIFY_LEVEL > 0. Fix: The attached patch simply stores and ignores the result returned from chown(). Regards, -Maynard |
From: John L. <le...@mo...> - 2007-04-04 22:10:55
|
On Wed, Apr 04, 2007 at 02:09:56PM -0500, Maynard Johnson wrote: > - chown(destination.c_str(), buf.st_uid, buf.st_gid); > + retval = chown(destination.c_str(), buf.st_uid, buf.st_gid); (void) chown(... is the usual trick for this sort of thing. Does gcc work out what that means correctly? regards john |
From: Maynard J. <may...@us...> - 2007-04-04 23:24:14
|
John Levon wrote: > On Wed, Apr 04, 2007 at 02:09:56PM -0500, Maynard Johnson wrote: > > >>- chown(destination.c_str(), buf.st_uid, buf.st_gid); >>+ retval = chown(destination.c_str(), buf.st_uid, buf.st_gid); > > > (void) chown(... > > is the usual trick for this sort of thing. Does gcc work out what that > means correctly? Nope. I get the same error as with original source. -Maynard > > regards > john |
From: John L. <le...@mo...> - 2007-04-04 23:30:00
|
On Wed, Apr 04, 2007 at 06:24:00PM -0500, Maynard Johnson wrote: > >>- chown(destination.c_str(), buf.st_uid, buf.st_gid); > >>+ retval = chown(destination.c_str(), buf.st_uid, buf.st_gid); > > > >(void) chown(... > > > >is the usual trick for this sort of thing. Does gcc work out what that > >means correctly? > Nope. I get the same error as with original source. Grumble, does tradition mean nothing round here!! Patch is fine. thanks john |
From: Maynard J. <may...@us...> - 2007-04-05 13:12:29
|
John Levon wrote: >On Wed, Apr 04, 2007 at 06:24:00PM -0500, Maynard Johnson wrote: > > > >>>>- chown(destination.c_str(), buf.st_uid, buf.st_gid); >>>>+ retval = chown(destination.c_str(), buf.st_uid, buf.st_gid); >>>> >>>> >>>(void) chown(... >>> >>>is the usual trick for this sort of thing. Does gcc work out what that >>>means correctly? >>> >>> >>Nope. I get the same error as with original source. >> >> > >Grumble, does tradition mean nothing round here!! > >Patch is fine. > > OK, I'll go ahead and commit the patch. Thanks, -Maynard >thanks >john > > |