The latest version of pdf_token_buffer_new puts an 'X' after every
buffer that's not null terminated.
The idea is that code treating the value as a C string, like
printf("%s\n", pdf_token_get_string_data(token));
will produce a value that's clearly incorrect. If we didn't do this,
sometimes a null byte would follow the buffer by chance, and the code
would appear to work.
That is a good idea.
> Also, I just spotted that there is no PDF_EBADDATA as return value of
> pdf_token_reader_new as stated in the manual.
The documentation states
PDF_EBADDATA: stm is not a reading stream.
but I don't see any API to get the mode of a stream.
Does anyone have a problem with a new public function
enum pdf_stm_mode_e pdf_stm_get_mode (pdf_stm_t stm); ?
I just committed a patch in the trunk providing that function.
--
Jose E. Marchesi <[email protected]>
http://www.jemarch.net
GNU Project http://www.gnu.org
