[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pdf-devel
Subject:    Re: [pdf-devel] Testing pdf.h.
From:       jemarch () gnu ! org
Date:       2008-02-29 23:20:09
Message-ID: 87tzjr9wpi.wl%jemarch () gnu ! org
[Download RAW message or body]


    >     > Thanks for clarifying Karl. BTW, distributing gnulib headers along with 
    >     > pdf.h is also a bad idea, isn't it? So the public API shouldn't depend 
    >     > on any data type coming from those headers.
    >     > 
    > 
    >    Then, I guess we have 3 ways to solve this:
    > 
    >    3. Build an abstraction level upon gl_list so the public API doesn't depend on
    >    gl_list.
    > 
    > It is the list module in the base layer.
    > 

   Duh !!, I didn't notice.

   I'm willing to help to implement the list module if there is no
   problem.

Thanks.

The implementation of the list module should be trivial. If you take a
look to the list module API (in the reference manual) you will find
that it is almost identical to the gl_list.h API. Inlined functions
wrapping the calls to gl_list_* would suffice.



[prev in list] [next in list] [prev in thread] [next in thread]