Re: cmdline_file_save accepts file handler instead

Lorenzo Bettini <[email protected]> Sat, 20 Oct 2007 18:58:04 +0200
Newsgroups gmane.comp.gnu.gengetopt.general
Message-ID <[email protected]>
Papp Gyozo (VBuster) wrote:
> Hi,
> 
> I debugged it but up to now I don't know what is wrong with.
> I made make clean && make check in the gengetopt 2.21 tests directory, log attached.
> 
> I found only one FAILED test: test_conf_parser_err_string.sh and not the one Lorenzo mentioned below:
> 

yes this makes sense since the previous patch, as you said in the 
previous email, was removing a vital instruction, so also the correct 
conf files were considered wrong.

>>> concerning the patch for config file, my tests for config file parsers
>> fail:
>>> test_conf_parser:./test_conf.conf:7: malformed string in configuration
>> file
>>> FAIL: test_conf_parser.sh
>>> could you please check this?
> 
> test_conf_parser_err_string.sh contains two test cases (attached):
> - first the test_conf_parser sample is executed on test_conf_err_string.conf
> - if it passes the previous test(!) then it will be tested against test_conf_err_string2.conf
> 
> Each test_conf file contains malformed strings.
> 
> I suspect that the second testcase had never ran before. Before applying my patch gengetopt rejected lines similar to this one from test_conf_err_string.conf
> 

actually, if you look at the .sh test

if $* ./test_conf_parser -r "bar" -a 100 -c 
@srcdir@/test_conf_err_string.conf; then
         false;
else
         if $* ./test_conf_parser -r "bar" -a 100 -c 
@srcdir@/test_conf_err_string2.conf; then
               false;
         else
               true;
         fi
fi

you see that the intent of the first if is to make sure that the call 
actually fails; and then checks that also the second call fails (the 
second call was always executed, if you take a look at test.out 
containing the output of all the tests).  Thus the test succeeds if both 
calls fail.

> multi-string = mal"formed"
> 
> My patch accepts this argument and treated as a valid string value as is (mal"formed") for the option 'multi-string'. That's why the next never executed testcase will fire, too, but it contains an invalid string value:
> 
> multi-string = "unterminated
> 
> I really hope I shed some light now. Is there any other volunteer to confirm my experience?

now, with your patch mal"formed" is not considered a malformed string 
anymore thus the first call does not fail, and the .sh returns false, 
that why the test fails.

As far as I understand, now only

"foo

is considered a bad string, while foo" would be considered as the string 
foo" right?

so I'm wondering, does it really make sense to consider "foo still a 
malformed string?

Actually, I'm still reluctant in considering mal"formed" a good argument 
since it is not consistent with command line arguments, where " must be 
escaped...

can we discuss a little bit on this?

thanks
	Lorenzo

-- 
Lorenzo Bettini, PhD in Computer Science, DSI, Univ. di Firenze
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