Re: [pdf-devel] Patch for FS#127

[Jonathan Harper]

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 <address@hidden> 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 <address@hidden> 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
>>
>