RE: Some of Aleksander's suggestions, I have revised the patch to fix some stylistic issues and change other function parameters to pdf_uchar_t. I *think* I covered everything in this version finally.
Thanks, Jonathan On Mon, May 9, 2011 at 1:16 PM, Jonathan Harper <jwh...@msstate.edu> wrote: > Let's try this again. The unit test error that occurred wasn't > actually due to any code that I changed, but file permissions on my > system. Whoops! > > Patch for FS#127 should be attached, with issues previously mentioned > fixed. I ran 'make syntax-check' and 'make check', with only the > known error occurring. > > Thanks, > Jonathan > > On Mon, May 9, 2011 at 9:15 AM, Aleksander Morgado <aleksan...@gnu.org> wrote: >> Hi hi, >> >>> >>> Thanks for looking over the patch. I didn't know about the "Date:" >>> headers, oops! I will fix these. I am not sure what you mean about >>> the argument name alignments. I thought I had preserved the alignment >>> of those. >>> >> >> About the alignments, see this example: >> >> pdf_bool_t >> -pdf_text_pdfdocenc_to_utf32he (const pdf_char_t *input_data, >> +pdf_text_pdfdocenc_to_utf32he (const pdf_uchar_t *input_data, >> const pdf_size_t input_length, >> - pdf_char_t **p_output_data, >> + pdf_uchar_t **p_output_data, >> pdf_size_t *p_output_length, >> pdf_error_t **error) >> >> After your change, "p_output_data" starts 1 position after all the other >> argument names. >> >>> I ran 'make check'. The following error occurs on both my branch and the >>> trunk: >>> base/stm/pdf-stm-write.c:989:F:pdf_stm_write:pdf_stm_write_016:0: >>> Failure 'memcmp (mem_stm_fixture.buf, decoded, 10) != 0' occured >>> >> >> Yeah, that's something I already have fixed in one of my WIP branches, >> will push that fix soon. >> >>> However, after my new changes, a new error occurs: >>> base/fsys/pdf-fsys-file-open.c:129:F:pdf_fsys_file_open:pdf_fsys_file_open_003:0: >>> Failure 'pdf_fsys_file_open (NULL, path, PDF_FSYS_OPEN_MODE_WRITE, >>> &file) != PDF_EBADPERMS' occured >>> >>> It seems I've managed to break something already. I've been trying to >>> figure out the source of the error. I think that it might have to do >>> with the conversion of 'path'. Thanks for being patient and pointing >>> out where I went wrong. >>> >> >> Yes, possibly something related to that. You'll have to dig in the >> specific failed unit test to see where the issue comes from... >> >> Ah, also, please always add a .txt or .diff extension to the patches, so >> that we can read them directly in our email reader (if email reader >> can't guess content type based on file extension, it won't show it). >> >> And one last thing, please try to keep pdf-devel mailing list always in >> the email loop, don't reply only to me (don't be afraid of posting to >> the list!) :-) >> >> Cheers and thanks for this work! >> >> -- >> Aleksander >> >
