pdf-devel
[Top][All Lists]
Advanced

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

Re: [pdf-devel] FS#79 text module and opaque pointers


From: jemarch
Subject: Re: [pdf-devel] FS#79 text module and opaque pointers
Date: Fri, 19 Dec 2008 00:41:28 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Hi Gerel.

   I'll do task #79.

Thanks.

   Some unit tests of the text module (in torture/unit/base/text/) are
   dereferencing pdf_text_t pointers. It is no longer working since the pdf-text
   module now publish "opaque pointers" in the public header file pdf.h.

   There are two possible solutions for this problem:

   1) To change the design of the tests to not have to use the internals of
      pdf_text_t
   2) To introduce a "testing" API in pdf_text providing access to the internal
      fields.
   ###

   First, a 3rd solution exists which is to leave all as it is and add a flag to
   disable opaque pointers when running the test cases.

I don't like the 3rd solution. We would be changing the software under
test just to be tested.

   Solution 1) is the most time consuming but the nicest too. Solution
   2) would be ok to me only if the introduced procedures are not just
   for testing purposes. Solution 3 is the simplest one.

I would go for solution 1. A lot of text tests are using something
like: 

  fail_unless(pdf_text_new_from_u32(number, &text) == PDF_OK);

... to set a value into the text object, and then

  fail_if(memcmp(text->data, expected_data, expected_size) != 0);

to check the expected value in text->data, that is the internal
unicode representation.

In those cases it would be better to validate pdf_text_new_from_u32
with pdf_text_get_unicode.

You may find a test that does not have a simple alternative using
public functions only. In that case we may discard the test.





reply via email to

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