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().