pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jonathan Harper
Subject: Re: [pdf-devel] Patch for FS#127
Date: Mon, 9 May 2011 14:14:40 -0500

How embarrassing, I forgot to attach the patch in the previous
message.  It is attached here.

On Mon, May 9, 2011 at 2:14 PM, Jonathan Harper <address@hidden> wrote:
> 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
>>>
>>
>

Attachment: jharper_uchar_patch.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]