On Monday 06 August 2012 02:45:28 Elden Tyrell wrote: > On Aug 5, 2012, at 11:19 PM, Mike Frysinger wrote: > > so %n is telling us how many *bytes* were read, not the number of > > elements consumed. > > Yes, but the *return value* is the "the number of input *items* assigned" (man sscanf); that's why I check that it's equal to 2 indicating that parsing didn't fail before reaching %n:
please read the documentation i quoted, as well as run the examples i posted. it does *not* return two. > if (sscanf(eq, "%lu%c", lu, &dummy) == 1) > > If there is junk left over the %c will match and it will return 2, and > 2!=1. that would also work > > however, i'd point out that this only catches errors where the user > > supplied a hex value that contains non-numbers. > > Yes, and that's the only situation where the user -- such as me -- is > thinking to themselves "well, I gave it something with letters in it, and > it didn't complain, so it can't possibly be parsing it as decimal or > octal!" > > Seriously, this is the reason why I never bothered trying a "0x" or "16'h" > prefix. i think you missed the point -- yes, we should catch underparsed hex values, but it wouldn't completely solve the problem. if your vid/pid happened to be fully numeric, then you still wouldn't have figured out that 0x was needed. -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
