Re: [pdf-devel] type 3 functions

[Hardy Falk]

Am Montag, 24. September 2007 16:06 schrieb address@hidden

> >  The occurence of function objects in a type 3 function
> >   dictionary makes pdf_func_t into a recursive data type.
> >  How is such an pdf_ obj_t constructed in the first place?
>
> The constructors for the several object types always takes
> non-object arguments (the stream is an exception, and makes a
> copy of the dict object):
>
> pdf_obj_t pdf_create_null (void);  
> ...
>pdf_obj_t pdf_create_stream (pdf_obj_t dict, pdf_stm_t stm, 
>pdf_stm_pos_t data);
>
> The constructor of the stream object could be changed to
> share the same dictionary object with the caller.
>
> Then, objects able to contain another objects (namely arrays
> and dictionaries) are created empty. The functions that adds
> elements to arrays and dictionaries do not make a copy of the
> inserted objects.
>
> >    Afaik, pdf_obj_t constructors make deep copies of their
> >   arguments.
>
> Only for strings and names. I will change it in my next cvs
> commit.

Thanks. I should have looked in more than one place. But then,
memory management *is* difficult.

A question along the same lines: 
How should we treat bad data, e.g. absurd sample table sizes? 
Careful argument checking ( xsize.h  ) should at least avoid 
exploitable allocation errors. OTOH, calling xmalloc() seems 
too harsh. A PDF viewer should report an error on a particular 
page, it should not die completely. Handling errors while 
avoiding memory leaks is even more difficult.
Shall we aim for this kind of robustness, or is it just a pipe 
dream?