Re: [sharutils-4.11.1] Compilation warnings

[Bruce Korb]

On 12/06/12 02:27, Petr Pisar wrote:
> On Wed, Dec 05, 2012 at 09:28:01AM -0800, Bruce Korb wrote:
>>
>> Meanwhile, in the intervening 18 months, there have been a few changes
>> that obliterated the unused variable.  I've now fixed the aliasing
>> issue, but I've not audited sharutils for full aliasing compliance.
>> Please give the pending release a spin:
>>
>> http://autogen.sourceforge.net/data/sharutils-4.12.2.tar.bz2
>>
> Great. It compiles and all tests pass on various architectures (i686, amd64,
> PPC, PPC64, S390, S390x). The original warnings have been resolved.
> 
> However a few new ones appeared in the bundled libopts code:
> 
> make[2]: Entering directory `/builddir/build/BUILD/sharutils-4.12.2/libopts'
> gcc -DHAVE_CONFIG_H -I. -I..  -I.  -Wno-format-contains-nul -O2 -g -pipe 
> -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
> --param=ssp-buffer-size=4  -m32 -Wno-format-contains-nul -c -o 
> libopts_a-libopts.o `test -f 'libopts.c' || echo './'`libopts.c
> In file included from libopts.c:28:0:
> genshell.c: In function 'AO_gettext':
> genshell.c:387:9: warning: implicit declaration of function 'dgettext' 
> [-Wimplicit-function-declaration]
> genshell.c:387:15: warning: incompatible implicit declaration of built-in 
> function 'dgettext' [enabled by default]

I do not have that problem.  Does this change to genshell.c fix it?

> #include <unistd.h>
> #ifdef HAVE_DCGETTEXT
> # include <gettext.h>
> #endif
> #include <autoopts/usage-txt.h>

> genshell.c:389:17: warning: assignment discards 'const' qualifier from 
> pointer target type [enabled by default]
> genshell.c:391:13: warning: assignment discards 'const' qualifier from 
> pointer target type [enabled by default]

Having AO_gettext return "char const *" is too difficult.
"_" is a macro, so I'm coerce casting its result to "char *":

>     res = (char *)(void *)_(pz);

> In file included from libopts.c:33:0:
> pgusage.c: In function 'optionPagedUsage':
> pgusage.c:67:9: warning: format '%lu' expects argument of type 'long unsigned 
> int', but argument 4 has type 'long long unsigned int' [-Wformat]

Yummy.  The type of the value was cast to uint64_t, but I guess I don't know 
what
that should map to.  So I'll cast the value to "unsigned long".  Since the value
is actually a PID number, I doubt it gets past 4 billion on 32 bit platforms.

> pgusage.c:112:9: warning: ignoring return value of 'system', declared with 
> attribute warn_unused_result [-Wunused-result]

>     112         (void)system(fil_name);
>     113     }

I explicitly cast the return value to void.  What does the blinking compiler 
want?
If the command succeeds, cool.  If not, there's nothing I can do about it but 
ignore it.
Consequently, the value is valueless.  If the compiler is going to complain 
about
an unused value when that value is explicitly cast to void, then it is a 
compiler bug.
They probably don't think so, but I think it is inexcusably stupid.

> And in shar.c:
> 
> shar.c: In function 'configure_shar':
> shar.c:1969:13: warning: ignoring return value of 'freopen', declared with 
> attribute warn_unused_result [-Wunused-result]

That is old code, but adding a check:
  if (isatty (fileno (output)) && isatty (STDERR_FILENO))
    {
      /*
       * Output is going to a TTY device, and so is stderr.
       * Redirect stderr to /dev/null in that case so that
       * the results are not cluttered with chatter.
       */
      FILE * fp = freopen ("/dev/null", fwriteonly_mode, stderr);
      if (fp != stderr)
        error (SHAR_EXIT_FAILED, errno,
               _("reopening stderr to /dev/null"));
    }

> The genshell.c and shar.c warnings exhibit everywhere, the psuage.c on 32-bit
> user space only.

Since I don't see the warnings on the two 64 bit platforms I have, I have to 
wait
for your feedback on the next iteration.  (or what you get with these patches on
what you have.  This isn't my day job....)

Thank you for your help!  Regards, Bruce