Sun, 8 Feb 2009, 04:09

A student has noticed that there is a bug in our function toNum that we
provide on the useful code page, specifically, it does not handle correctly
hex strings longer than seven hex digits.  

First, to the student who caught it: Thank you!

Second, we have fixed the bug, so if you had not encountered it previously, 
you will not encounter it now.

Finally (in any case), if you have already submitted your assembler and 
you used toNum, you do not need to worry about it since NONE of our test 
cases have hex strings longer than 7 hex digits and so toNum will behave
properly on our test cases.

	
	
	Dr. Patt,

	On the useful code page you provide a function called toNum. 
	That function has a bug in it.

	To convert a hexadecimal string to an int, it uses this code:
	   sprintf( lBuf, "0x%s", pStr );        /* convert hex string 
	into integer */
	   sscanf( lBuf, "%i", &lNum );

	However, lBuf is declared as:
	   char lBuf[10];

	This means that the sprintf will overflow lBuf when pStr is longer 
	than 7 characters (and corrupt the stack).



That is true.  Now toNum will return a value for longer strings, although
(as is true for even seven hex digits) the value returned is too big to make 
any sense.

	
	
	The golden assembler appears to be able to handle any length number 
	(within the maximum line length).

	Should our assembler be able to handle hexadecimal numbers longer than 7
	characters? 



THIS IS THE MAJOR question at this point.
Answer (again): No.  

	
	
	A quick fix is to make lBuf MAX_LINE_LENGTH+2 characters 
	long (conservative, but will do the job).

	<<name withheld to protect the very helpful student>>



Again, thank you for pointing this out.

Yale Patt