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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Andre Noll]

On 21:07, Lorenzo Bettini wrote:
> I'm responding in the mailing list help-gengetopt (you're subscribed to
> it, aren't you?)

Sure I am.

> >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).

OK. Another solution would be to let all object files depend on Makefile
which is also generated by configure.

> >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.

I see. An alternative for getting rid of this warning is to introduce an
intermediate (void *) cast:

        free_multiple_field (args_info->user_allow_given, (void **)(void *)&(args_info->user_allow_arg), &(args_info->user_allow_orig));
                                                                   ^^^^^^^^
> Actually, I don't get this warning, so thanks for reporting it.

You need to compile with -Wstrict-aliasing (included in -Wall) and
with -fstrict-aliasing (enabled at levels -O2, -O3, -Os).

Have fun
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Andre Noll wrote:

>>> 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).
>
> OK. Another solution would be to let all object files depend on Makefile
> which is also generated by configure.
>

mhh... but I don't know whether this can be made in a clean way with
autotools...  I'm pretty sure that configure for different architectures
should be run in different directories...

>>> 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.
>
> I see. An alternative for getting rid of this warning is to introduce an
> intermediate (void *) cast:
>
> free_multiple_field (args_info->user_allow_given, (void **)(void *)&(args_info->user_allow_arg), &(args_info->user_allow_orig));
>                                                                    ^^^^^^^^

well if this does not generate the warning I think that'd be a better
solution :-)

>> Actually, I don't get this warning, so thanks for reporting it.
>
> You need to compile with -Wstrict-aliasing (included in -Wall) and
> with -fstrict-aliasing (enabled at levels -O2, -O3, -Os).

actually I always test compilations with -Wall but I don't get this
warning... probably because you're using a different architecture?  Is
this warning something to worry about?  I mean: I want to remove it, but
does the warning means that the above code can do something wrong?

thanks
        Lorenzo

P.S. there are also other warnings that I still need to remove; Gyozo, I
didn't remember to remove all the warnings you told me about; I'll do
that in the very near future :-)

--
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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Andre Noll]

On 22:52, Lorenzo Bettini wrote:

> >OK. Another solution would be to let all object files depend on Makefile
> >which is also generated by configure.
> >
>
> mhh... but I don't know whether this can be made in a clean way with
> autotools...

IMHO this has nothing to do with autotools. Wouldn't "%.o: Makefile" in
Makefile.in do the trick?

>   I'm pretty sure that configure for different architectures
> should be run in different directories...

I tend to disagree: It should also be possible to use the configure
script to reconfigure a software package, either for the same arch
(but using other options for example) or for another arch.

Anyway, it's just a minor issue, so don't worry too much.


[dereferencing type-punned pointer will break strict-aliasing rules]

> >I see. An alternative for getting rid of this warning is to introduce an
> >intermediate (void *) cast:
> >
> > free_multiple_field (args_info->user_allow_given, (void **)(void
> > *)&(args_info->user_allow_arg), &(args_info->user_allow_orig));
> >                                                                   ^^^^^^^^
>
> well if this does not generate the warning I think that'd be a better
> solution :-)

Yes, this makes the warning go away.

> >>Actually, I don't get this warning, so thanks for reporting it.
> >
> >You need to compile with -Wstrict-aliasing (included in -Wall) and
> >with -fstrict-aliasing (enabled at levels -O2, -O3, -Os).
>
> actually I always test compilations with -Wall but I don't get this
> warning... probably because you're using a different architecture?

You need -Wall _and_ one of the -O flags (or -fstrict-aliasing). I
get the warning on a ubuntu Linux system on x86_64 using gcc-4.1.2,
nothing fancy.

> Is this warning something to worry about?  I mean: I want to remove
> it, but does the warning means that the above code can do something
> wrong?

The warning is harmless if the code doesn't use type-punning (reading
from a different union member than the one most recently written
to). The only union in the files generated by gengetopt is

        union generic_value {
            int int_arg;
            char *string_arg;
        };

for which type-punning doesn't make much sense. So I'm pretty sure
it is harmless.

Regards
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

Hi

> [dereferencing type-punned pointer will break strict-aliasing rules]

I also met this warning several times in different projects but I still don't know by heart in what circumstances it happens for sure. But look at the GCC documentation:

For C (and C++),  about -fstrict-aliasing
     
     this activates optimizations based on the type of expressions.  In
     particular, an object of one type is assumed never to reside at
     the same address as an object of a different type, unless the
     types are almost the same.  For example, an `unsigned int' can
     alias an `int', but not a `void*' or a `double'.  A character type
     may alias any other type.

You should also note that, as far as I know, this kind of data access violates the C99 aliasing rules. (I think mostly because of alignment and other size-related problems.)


> union generic_value {
>    int int_arg;
>    char *string_arg;
> };
>
> for which type-punning doesn't make much sense. So I'm pretty sure
> it is harmless.

IMHO this is not the case due to the fact type-punning is not restricted to unions. (But you are right one of the workarounds is to use type-pun unions with all types possibly to use.) However the warning here may be harmless probably.


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Hi

I've uploaded this candidate for the next version that should remove all
the warnings:

http://gdn.dsi.unifi.it/~bettini/gengetopt-2.22.1.tar.gz

and for the type punning question, I preferred not to pass a void **
pointer (I zero the pointer outside the function).

Could you please check this version?  I tried to recreate your compiler
command line arguments so that I got the warnings too; now, with make
check, I don't get warnings anymore...

thanks
        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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Lorenzo Bettini wrote:

> Hi
>
> I've uploaded this candidate for the next version that should remove all
> the warnings:
>
> http://gdn.dsi.unifi.it/~bettini/gengetopt-2.22.1.tar.gz
>
> and for the type punning question, I preferred not to pass a void **
> pointer (I zero the pointer outside the function).
>
> Could you please check this version?  I tried to recreate your compiler
> command line arguments so that I got the warnings too; now, with make
> check, I don't get warnings anymore...
>

anyone tried this?

--
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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Tim Post-3]

On Wed, 2008-01-30 at 09:18 +0100, Lorenzo Bettini wrote:

> Lorenzo Bettini wrote:
> > Hi
> >
> > I've uploaded this candidate for the next version that should remove all
> > the warnings:
> >
> > http://gdn.dsi.unifi.it/~bettini/gengetopt-2.22.1.tar.gz
> >
> > and for the type punning question, I preferred not to pass a void **
> > pointer (I zero the pointer outside the function).
> >
> > Could you please check this version?  I tried to recreate your compiler
> > command line arguments so that I got the warnings too; now, with make
> > check, I don't get warnings anymore...
> >
>
> anyone tried this?
>

About to, this looks extremely useful :) I'm in the middle of two papers
and making valgrind be quiet on something else, or I'd have chirped in
sooner.

I'm one of the lead developers for GNUPanel, we're in the middle of
writing some distro/technology agnostic virtualization controls as well
as re-writing a bunch of stuff done in perl to C. I will give this quite
a workout, I promise :)

Cheers,
--Tim



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Andre Noll]

On 09:18, Lorenzo Bettini wrote:

> >and for the type punning question, I preferred not to pass a void **
> >pointer (I zero the pointer outside the function).
> >
> >Could you please check this version?  I tried to recreate your compiler
> >command line arguments so that I got the warnings too; now, with make
> >check, I don't get warnings anymore...
> >
>
> anyone tried this?

Yes, I just tried it, and I can confirm that the code generated by this
gengetopt version doesn't cause gcc to spit out the type punning
warnings.

Thanks a lot, Lorenzo
Andre
--
The only person who always got his work done by Friday was Robinson Crusoe


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Andre Noll wrote:

> On 09:18, Lorenzo Bettini wrote:
>
>>> and for the type punning question, I preferred not to pass a void **
>>> pointer (I zero the pointer outside the function).
>>>
>>> Could you please check this version?  I tried to recreate your compiler
>>> command line arguments so that I got the warnings too; now, with make
>>> check, I don't get warnings anymore...
>>>
>> anyone tried this?
>
> Yes, I just tried it, and I can confirm that the code generated by this
> gengetopt version doesn't cause gcc to spit out the type punning
> warnings.
>
> Thanks a lot, Lorenzo
> Andre

Thank you for the feedback :-)

I think I'll release 2.22.1 soon, then

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> Lorenzo Bettini wrote:
> > I've uploaded this candidate for the next version that should remove all
> > the warnings:
> >
> > http://gdn.dsi.unifi.it/~bettini/gengetopt-2.22.1.tar.gz


Sorry for the big delay and brothering you but I'm experiencing that multiple line parsing for description string does not work. Here is the simpliest example:

option  "quiet"             q
"control message verbosity on stdout.
`-q' does not print file names.
`-qq' suppresses all messages but alerts, and
`-qqq' implies `--terse' as well.
It does not affect error reporting on stderr!"
    no multiple

and the result will be:

gengetopt:10: syntax error `
gengetopt:10: `-q' does not print name of clean files.'
gengetopt:10: ^

The commandline was 'gengetopt -f getoptions -acmdline_options -uTARGETS -CeN'

$ gengetopt --version
GNU gengetopt 2.22.1


I think it was good with previous betas (2.22b)


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:

>> Lorenzo Bettini wrote:
>>> I've uploaded this candidate for the next version that should remove all
>>> the warnings:
>>>
>>> http://gdn.dsi.unifi.it/~bettini/gengetopt-2.22.1.tar.gz
>
>
> Sorry for the big delay and brothering you but I'm experiencing that multiple line parsing for description string does not work. Here is the simpliest example:
>
> option  "quiet"             q
> "control message verbosity on stdout.
> `-q' does not print file names.
> `-qq' suppresses all messages but alerts, and
> `-qqq' implies `--terse' as well.
> It does not affect error reporting on stderr!"
>     no multiple
>
> and the result will be:
>
> gengetopt:10: syntax error `
> gengetopt:10: `-q' does not print name of clean files.'
> gengetopt:10: ^
>
> The commandline was 'gengetopt -f getoptions -acmdline_options -uTARGETS -CeN'
>
> $ gengetopt --version
> GNU gengetopt 2.22.1
>
>
> I think it was good with previous betas (2.22b)
>

hi there

thanks for the bug report

I think this was always there: probably I forgot to include ` as a valid
char in the string.

I'll check this out next week

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



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:

>> Lorenzo Bettini wrote:
>>> I've uploaded this candidate for the next version that should remove all
>>> the warnings:
>>>
>>> http://gdn.dsi.unifi.it/~bettini/gengetopt-2.22.1.tar.gz
>
>
> Sorry for the big delay and brothering you but I'm experiencing that multiple line parsing for description string does not work. Here is the simpliest example:
>
> option  "quiet"             q
> "control message verbosity on stdout.
> `-q' does not print file names.
> `-qq' suppresses all messages but alerts, and
> `-qqq' implies `--terse' as well.
> It does not affect error reporting on stderr!"
>     no multiple
>
> and the result will be:
>
> gengetopt:10: syntax error `
> gengetopt:10: `-q' does not print name of clean files.'
> gengetopt:10: ^
>
> The commandline was 'gengetopt -f getoptions -acmdline_options -uTARGETS -CeN'

Hi there

I tried your code and it works fine with me... could you please send me
the file that experiences this problem?

I suspect it's a problem with newline chars...

thanks
        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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Gyozo Papp]

Hi.

>  > option  "quiet"             q
>  > "control message verbosity on stdout.
>  > `-q' does not print file names.
>  > `-qq' suppresses all messages but alerts, and
>  > `-qqq' implies `--terse' as well.
>  > It does not affect error reporting on stderr!"
>  >     no multiple
>  >
>  > and the result will be:
>  >
>  > gengetopt:10: syntax error `
>  > gengetopt:10: `-q' does not print name of clean files.'
>  > gengetopt:10: ^
>  >
>  > The commandline was 'gengetopt -f getoptions -acmdline_options -uTARGETS -CeN'
>
>  I tried your code and it works fine with me... could you please send me
>  the file that experiences this problem?
>
>  I suspect it's a problem with newline chars...

It must be. Quite strange but the mingw build on Windows works fine
while the Linux one produce this error. Tomorrow I'll attach the
original fil.e

--
Papp, Gyozo


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Gyozo Papp wrote:

> Hi.
>
>>  > option  "quiet"             q
>>  > "control message verbosity on stdout.
>>  > `-q' does not print file names.
>>  > `-qq' suppresses all messages but alerts, and
>>  > `-qqq' implies `--terse' as well.
>>  > It does not affect error reporting on stderr!"
>>  >     no multiple
>>  >
>>  > and the result will be:
>>  >
>>  > gengetopt:10: syntax error `
>>  > gengetopt:10: `-q' does not print name of clean files.'
>>  > gengetopt:10: ^
>>  >
>>  > The commandline was 'gengetopt -f getoptions -acmdline_options -uTARGETS -CeN'
>>
>>  I tried your code and it works fine with me... could you please send me
>>  the file that experiences this problem?
>>
>>  I suspect it's a problem with newline chars...
>
> It must be. Quite strange but the mingw build on Windows works fine
> while the Linux one produce this error. Tomorrow I'll attach the
> original fil.e
>

Hi there

I cannot seem to reproduce the problem (even with dos newlines), could
you please send me the file?

thanks
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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> >>  > gengetopt:10: syntax error `
> >>  > gengetopt:10: `-q' does not print name of clean files.'
> >>  > gengetopt:10: ^
> >>  >
> >>  > The commandline was 'gengetopt -f getoptions -acmdline_options
> -uTARGETS -CeN'
> >>
> >>  I tried your code and it works fine with me... could you please send me
> >>  the file that experiences this problem?

> I cannot seem to reproduce the problem (even with dos newlines), could
> you please send me the file?

It may be nothing to do with gengetopt but the way I create the ggo file.

Actually the original .ggo file is rather a template which is filled in with cpp preprocessor (replace defines with real string values for option defaults and such):

        $(CC) -I $(THISDIR) $(CFLAGS) $(defines) -E -x c $(THISDIR)/$< \
        | tee options.processed \
        | $(GENGETOPT) -f getoptions -acmdline_options -uTARGETS -CeN

the original lines above look like from options.processed:

option "quiet" q
"control message verbosity on stdout."
 `-q' does not print name of clean files.'
 `-qq' suppresses all messages but alerts, and'
 `-qqq' implies terse' as well.
It does not affect error reporting on stderr!""
        no multiple

Each unterminated quote (both single and double) is terminated automagically, that's why gengetopt fails.


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Lorenzo Bettini]

Papp Gyozo (VBuster) wrote:

>>>>  > gengetopt:10: syntax error `
>>>>  > gengetopt:10: `-q' does not print name of clean files.'
>>>>  > gengetopt:10: ^
>>>>  >
>>>>  > The commandline was 'gengetopt -f getoptions -acmdline_options
>> -uTARGETS -CeN'
>>>>  I tried your code and it works fine with me... could you please send me
>>>>  the file that experiences this problem?
>
>> I cannot seem to reproduce the problem (even with dos newlines), could
>> you please send me the file?
>
> It may be nothing to do with gengetopt but the way I create the ggo file.
>
> Actually the original .ggo file is rather a template which is filled in with cpp preprocessor (replace defines with real string values for option defaults and such):
>
>         $(CC) -I $(THISDIR) $(CFLAGS) $(defines) -E -x c $(THISDIR)/$< \
>         | tee options.processed \
>         | $(GENGETOPT) -f getoptions -acmdline_options -uTARGETS -CeN
>
> the original lines above look like from options.processed:
>
> option "quiet" q
> "control message verbosity on stdout."
>  `-q' does not print name of clean files.'
>  `-qq' suppresses all messages but alerts, and'
>  `-qqq' implies terse' as well.
> It does not affect error reporting on stderr!""
>         no multiple
>
> Each unterminated quote (both single and double) is terminated automagically, that's why gengetopt fails.
>

So there's no problem in gengetopt, right?

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


_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt

[Papp Gyozo (VBuster)]

> > Each unterminated quote (both single and double) is terminated
> automagically, that's why gengetopt fails.
>
> So there's no problem in gengetopt, right?

No, it must be due to a unknown cpp feature. The following hack works:

option "quiet" q
"control message verbosity on stdout.\
\n`-q' does not print name of clean files.\
\n`-qq' suppresses all messages but alerts, and\
\n`-qqq' implies terse' as well."

Not so nice but it works. Sorry for the noise.



_______________________________________________
Help-gengetopt mailing list
Help-gengetopt@...
http://lists.gnu.org/mailman/listinfo/help-gengetopt