On Monday 06 August 2012 01:44:18 Elden Tyrell wrote: > On Aug 5, 2012, at 7:23 PM, Mike Frysinger wrote: > >> jtag> cable gnICE+ VID=15ba PID=002a > > > > if you use 0x15ba, does it work better ? > > Yep, that works: > > jtag> cable gnICE+ vid=0x15ba pid=0x002a > Connected to libftdi driver. > > There is a bug in the error checking code in params.c that causes it to > silently ignore sscanf() errors so long as at least a single character is > consumed; in my case it stopped after "15" and "0002" rather than complain > about the fact that "15ba" and "002a" are not decimal numbers. > > The attached patch causes it to parse the entire input rather than an > arbitrary nonempty prefix of it.
i'm not sure how this can work. POSIX states for %n:
No input is consumed. The application shall ensure that the corresponding
argument is a pointer to the integer into which shall be written the number of
bytes read from the input so far by this call to the fscanf() functions.
Execution of a %n conversion specification shall not increment the assignment
count returned at the completion of execution of the function. No argument
shall be converted, but one shall be consumed. If the conversion specification
includes an assignment-suppressing character or a field width, the behavior is
undefined.
so %n is telling us how many *bytes* were read, not the number of elements
consumed. further, it's not telling us how things are being interpreted --
dec, hex, oct, whatever. we made a conscious decision to only support hex
numbers that start with 0x to avoid ambiguity. if there are places where the
documentation can be made more clear, then we should update that.
back to the patch at hand, if we look at two cases here, we see it doesn't
actually work:
sscanf("0a", "%lu%n", lu, &dummy);
- lu = 0 (wrong)
- "a" left unconsumed in the input string (wrong)
- dummy = 1
- return value = 1
sscanf("0111", "%lu%n", lu, &dummy);
- lu = 111 (wrong)
- input string completely consumed
- dummy = 4
- return value = 1
i'm guessing what you actually want is:
int dummy;
if (sscanf(eq, "%lu%n", lu, &dummy) == 1 && eq[dummy] == '\0')
return URJ_STATUS_OK;
however, i'd point out that this only catches errors where the user supplied a
hex value that contains non-numbers. it can't tell that when the user entered
"0111", they actually meant "0x111". or maybe they did actually mean "0111",
so this core function shouldn't be rejecting it in the first place.
maybe as part of the cable output, we can echo back "forcing VID=0x1234" so
that they can immediately tell "oh, my number is being interpreted as a
decimal when i really want hex, so i need to add the 0x prefix".
-mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ UrJTAG-development mailing list UrJTAG-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/urjtag-development
