Greetings,
Our "OpenBIOS guy" thinks he found a bug in the tokenizer. Can you comment? What's the procedure for submitting fixes?
Looks like my previous post attempt was screwed up by Lotus notes, trying again...
----- Mark Wenning wenning@us.ibm.com 1-512-838-6263 Global FirmWare: Networking and I/O, FC lackey ----- Experience is what you get when you were expecting something else. - Anon ----- ----- Forwarded by Mark W Wenning/Austin/IBM on 03/07/2005 10:02 AM ----- David L Paktor/Almaden/IBM 03/04/2005 05:33 PM To wenning@us.ibm.com cc
Subject Re: Found a serious bug in OpenBios Tokenizer
Hi, Mark.
As we spoke, I'm giving you some additional detail to describe the bug I found.
Here's a recap of what I wrote before:
It has to do with fload ; When your source fload s a file, that file is supposed to be a continuation of your source-stream.
New definitions, as they are processed in the Tokenizer, are supposed to get successive FCode tokens assigned to them, starting at 0x0800.
But when the OpenBios Tokenizer fload s a new file, it resets the FCode token-number, and starts assigning tokens from 0x0800 again. So if you have:
definition A definition B definition C definition D
\ and then
fload File1 \ which has:
definition E definition F definition G definition H
and then you have something that intends to invoke A B C or D you will instead get E F G or H , respectively....
Here's the additional material:
The source of the problem can be traced to the routines: init_stream and init_output in the file stream.c . They are both called at the beginning of tokenization, one to prepare the source from which input will be scanned, and the other to prepare the area to which output will be delivered (broadly speaking). When the fload directive is encountered, the input source is suspended and a new one is activated; when the new one is exhausted, the previous one is re-activated at the point from which it was suspended. So far so good. The init_stream routine is called to effectuate that activation. Unfortunately, the line that initializes the FCode token-numbers being assigning to new definitions -- the variable called nextfcode -- occurs inside the init_stream routine.
I believe that moving that line to the init_output routine is sufficient to fix this bug.