Hi David.
Regarding your patch on error management in type4 functions...
- Fix a bug in the real numbers reader. I wrote parse_real function which
works, though it does not check overflows. It should be moved to the
tokenizer module.
Superb, thanks.
- A code as the following compiled without errors, but the evaluator crashed:
{
...
{
...
}
...
} if
...
} if
}
The patch fixes this bug.
- pdf_fp_func_4_new reports errors correctly. It reports the position
of the error in the code too. I use the return value to do this.
- pdf_fp_func_eval reports interpretation errors in type 4 functions
correctly. I added some debug information to the function structure
in addition to the opcode. So, the evaluator can get the offset of a
interpretation error in the code, and inspect the current context
(the stack). However, the documentation does not describe the debug
structure yet.
Quite useful. I just created a task covering the documentation of the
new facility.
- Add negative unit testing for the above-named.
Finally the type 4 evaluator does not check some `bad type'
errors. The reason is that two special real numbers stand for logic
values:
#define REP_TRUE (1.202056903159594285399738162)
#define REP_FALSE (-15116315767.09215686274509804)
It is not very smart for me reporting errors so.
I wait you give me some feedback.
What `bad type' errors are those?
In the meanwhile I applied the patch in the trunk. Many thanks :)
--
Jose E. Marchesi <[email protected]>
http://www.jemarch.net
GNU Project http://www.gnu.org
