Bug 81 - CommandLine::AddArgValue not working correctly
CommandLine::AddArgValue not working correctly
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: core
pre-release
PC Linux
: P1 minor
Assigned To: ns-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-02 08:51 UTC by Gustavo J. A. M. Carneiro
Modified: 2007-10-10 10:20 UTC (History)
0 users

See Also:


Attachments
patch (1.96 KB, patch)
2007-10-08 12:30 UTC, Gustavo J. A. M. Carneiro
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gustavo J. A. M. Carneiro 2007-10-02 08:51:38 UTC
./build/debug/samples/main-default-value --loops 1
You requested 10977 iterations of a loopiteration 0iteration 1iteration 2iteration 3iteration 4....

valgrind says:
==24210== Conditional jump or move depends on uninitialised value(s)
==24210==    at 0x402B8C: main (main-default-value.cc:63)

line 63 is:

  if(loops>0)

Even though loops was initialized to zero at start, it sounds like CommandLine::Parse copied an undefined value over it.
Comment 1 Mathieu Lacage 2007-10-08 02:41:58 UTC
This bug is just a bug about not reporting a more friendly error about invalid input.
Comment 2 Mathieu Lacage 2007-10-08 02:57:16 UTC
(In reply to comment #1)
> This bug is just a bug about not reporting a more friendly error about invalid
> input.

To me specific, what I mean is that the example command-line is erronous. It shows:
./build/debug/samples/main-default-value --loops 1
while it should show:
./build/debug/samples/main-default-value --loops=1

So, the problem is really that we do not detect an invalid syntax.
Comment 3 Gustavo J. A. M. Carneiro 2007-10-08 12:28:36 UTC
As usual, I didn't mean to make this a "blocker" bug; it is merely the default severity for newly created bugs...
Comment 4 Gustavo J. A. M. Carneiro 2007-10-08 12:30:35 UTC
Created attachment 74 [details]
patch

Patch to:
  1. Support both --option=value and also --option value
  2. Don't overwrite user variable with a undefined value when parsing fails
  3. Give a warning when parsing of the value fails
Comment 5 Mathieu Lacage 2007-10-09 02:06:18 UTC
The summary below sounds great

>   1. Support both --option=value and also --option value
>   2. Don't overwrite user variable with a undefined value when parsing fails
>   3. Give a warning when parsing of the value fails

It would be awesome if you could manage to add some tests which exercise these problems. If you can't, would you mind file another bug to keep track of the lack of tests for this code ?

Comment 6 Gustavo J. A. M. Carneiro 2007-10-09 06:39:04 UTC
Committed (with unit tests, and other minor tweaks)
Comment 7 Tom Henderson 2007-10-10 10:20:13 UTC
(In reply to comment #3)
> As usual, I didn't mean to make this a "blocker" bug; it is merely the default
> severity for newly created bugs...
> 

I changed the default severity to normal, and added default "All" for the platform and OS fields.