> Would be useful to return more detailed information: it would be
> really difficult to fix a buggy function facing something like
> "Internal error". But it would be quite difficult to do it in a
> generic way.
>
> What about adding a new specific `pdf_fp_func_4_eval' function? It
> would break the generic function application schema, but we can always
> expand the API to ask a function its type.
>
> What do you think?
I think we could use an extra union structure argument for this. We could
use the return value to specify generic errors listed previously, and the
extra argument in order to get more detailed info.
Seems ok to me. But in that case we should add a new pdf_status_t
value indicating that there is additional error data in the extra
argument. Somthing like PDF_ETYPE4.
Anyway, as far I know, other type functions should not fail, right?
They can fail: the pdf_eval_* functions in pdf-fp-func.c can return
pdf_status_t values other than PDF_OK.
I read the operands from PostScript Reference Language. We should report
following errors:
- stackoverflow
- stackunderflow
- typecheck
- undefinedresult
- rangecheck
Ok.
Finally we could include what operator failed, offset in the code,
even a copy of the stack if this was useful for debugging.
I would include all of them.
--
Jose E. Marchesi <[email protected]>
http://www.jemarch.net
GNU Project http://www.gnu.org
