[help-gengetopt] Re: GNU Gengetopt 2.22

[Lorenzo Bettini]

Andre Noll wrote:
> Hi

Hi Andre

I'm responding in the mailing list help-gengetopt (you're subscribed to 
it, aren't you?)

> On 17:09, Lorenzo Bettini wrote:
>
> > GNU Gengetopt 2.22 has been released.
>
> Great. I successfully compiled it on Linux/x86/64 and on Mac/ppc32,
> but I'm having some minor issues with the new version:

great!

> Compiling gengetopt-2.22 on MacOS yields the warning
>
>         cmdline.c:708: warning: passing argument 2 of 'rpl_getopt_long' 
> discards qualifiers from pointer target type
>
> I have no idea what rpl_getopt_long is and how to fix this warning.

well this is probably due to the fact that the MacOS version of 
getopt_long is not standard and so the one that comes with the package 
is used, but it declares one of the parameters as const while it should 
not be like that (or the other way round).  This should be no problem, 
and probably the version of getopt.c that I'm using (that comes from the 
gnulib project) should be updated; I'll check this.

> The second issue is that re-configuring does not cause all files to
> be rebuilt.  I noticed this by first compiling and installing
> gengetopt-2.22 on Linux. Then, from the same directory (which is
> exported over NFS) I did on the Mac
>
>         ./configure && make
>
> and this gave me
>
>         /usr/bin/ld: argsdef.o bad magic number (not a Mach-O file),
>
> /usr/bin/ld is right: argdef.o is an ELF x86-64 File, so it  wasn't
> rebuild, but it should have been.
>
> Similarly, if gengetopt is compiled on Mac, and then configured and
> built on Linux, it results in
>
>         argsdef.o: file not recognized: File format not recognized
>         
> However, this is not a serious issue because "make clean" solves the
> problem.

mh... I don't think this is the expected behavior: issueing another 
configure might change the config.h and the files that include it will 
be recompiled, but not all files are expected to include it; actually if 
you build a package for different platforms you should run each 
configure in a separate directory (one for each different configure).

I'm pretty sure this is expected behavior though I couldn't bet on it :-)

> Finally, when compiling audiod.cmdline.c, a file generated by
> gengetopt-2.22, I see the following warning, which didn't show up
> when using earlier versions of gengetopt:
>
> audiod.cmdline.c: In function 'audiod_cmdline_parser_release':
> audiod.cmdline.c:337: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
>
> The offending line 337 in audiod.cmdline.c is
>
>           free_multiple_field (args_info->user_allow_given, (void 
> **)&(args_info->user_allow_arg), &(args_info->user_allow_orig));
>
> And free_multiple_field() looks like this:
>
> static void
> free_multiple_field(unsigned int len, void **arg, char ***orig)
> {
>   unsigned int i;
>   if (*arg) {
>     for (i = 0; i < len; ++i)
>       {
>         free_string_field(&((*orig)[i]));
>       }
>
>     free (*arg);
>     *arg = 0;
>     free (*orig);
>     *orig = 0;
>   }
> }
>
> Why you are using void ** as the second parameter "arg" when the function
> is only using *arg? Wouldn't it be better to generate
>
> static void
> free_multiple_field(unsigned int len, void *arg, char ***orig)
> {
>   unsigned int i;
>   if (arg) {
>     for (i = 0; i < len; ++i)
>       {
>         free_string_field(&((*orig)[i]));
>       }
>
>     free (arg);
>     free (*orig);
>     *orig = 0;
>   }
> }
>
> instead? This would allow to get rid of the cast in the offending line.
> The only drawback I can see is that args_info->user_allow_arg is not
> set to NULL by free_multiple_field() when using this approach.

mh... setting that arg to null is crucial (since what is freed could be 
re-used internally), but probably I could set it to NULL after that 
function call, I'll take a look at this.

Actually, I don't get this warning, so thanks for reporting it.

hope to hear from you soon
cheers
        Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net