pdf-devel
[Top][All Lists]
Advanced

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

Re: [pdf-devel] Public API and gl_list


From: Cirilo Bernardo
Subject: Re: [pdf-devel] Public API and gl_list
Date: Thu, 13 Mar 2008 07:37:21 +0000

On Thu, Mar 13, 2008 at 1:38 AM, Juan Pedro Bolivar Puente
<address@hidden> wrote:
> Hi,
>
>  Another issue with pdf_list_t implementation. All inline functions are
>  declared in the .c source. If you actually want to allow the compiler
>  inline them, you need to define them in the header file. As inlining is
>  important in my opinion in such wrapper functions, I'd rather put them
>  in the .h.
>
>  JP

Well spotted.

As for the list implementation, calling 'die' really should be
considered as broken behavior in this case; for example, the calling
program may decide to free all allocated memory and attempt to print a
message to stderr (wherever it may be redirected) so that the user can
find out what went wrong.  This may actually succeed even if memory is
low and malloc() failed in the GNU library.  If 'die' is called, we
have no idea what failed, when, or why. For all we know it was a
segfault rather than low memory.  The GNU guidelines do state that
interactive programs should die in such a case (although I'd still
prefer to attempt to print a message rather than mysteriously
quitting), but a library can never be considered 'interactive' except
in the special case where it is statically linked (which is pretty
rare).

I doubt the GNU people will change the behavior though; that may
affect too many other programs.  Let's see how it goes - worst case is
we fork the list code.

- Cirilo




reply via email to

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