Email has started, and as always, I am glad to respond to questions posed via email at any time, as those of you who were with me in 306 well know. However, when it comes to the programming labs, you are probably better off going to the TAs. In general, they have more current and often better experience with the lab. Meanwhile, indeed, a student writes:
Hello Dr. Patt, I was just testing my assembler and realized that the toNum functions posted on the useful code webpage can recieve bad input and not error propperly. Using those functions to convert/test constants in my code, the following bit of bad code is allowed. .orig x3000 .fill xThisIsNotAValidConstant .fill #Neither-Is-This .end Do we need to add in additional error checking of our own to test this? Or should we rely on the toNum functions not being given bad input? Thanks, <<name withheld to protect the nephew of Sherlock Holmes>>
Ooops! You are correct. toNum() will not detect the errors in the example program you wrote. Shame on us! So, it looks like there are two solutions to this: 1. We fix toNum() so that it does detect this kind of error. Done, compliments of Jose. It will be posted on the web site within the next hour. So, you can use the "new" toNum() and do not have to add additional error checking of your own to deal with this case. 2. We can make sure we do not include test cases that have such bad input just in case someone has already done the assignment and has not noticed that toNum() was broken. So, given #2, I think the fairest thing is for us to not provide test cases that will incorrectly be passed by the old toNum().