Re: how to mix or avoid perl and gnulib headers and object files together?

[Patrice Dumas]

On Fri, Feb 23, 2024 at 07:27:55PM +0000, Gavin Smith wrote:
> > First a question.  Is the mixing of perl and gnulib functions bad at
> > compile time only or also at link time?
> 
> It is bad at any time.  I'm not sure what situation you refer to by "link
> time".  As far as I understand, the Perl headers redefine (or can redefine)
> the symbol "free" to something else, e.g. "Perl_free".  This means the
> ensuing object files will reference a different symbol, instead of just
> "free".  That reference will persist and remain a problem at link time.

Ok, this is clear. 

> >  A somewhat related question
> > is can code like
> > #if defined _WIN32 && !defined __CYGWIN__
> >   #undef free
> > #endif
> > be removed if the C file does not include the gnulib headers but is
> > eventually part of a binary object including binary objects compiled
> > from gnulib code?
> 
> I would think that it can be.  The comment above that code is
> 
> /* Avoid warnings about Perl headers redefining symbols that gnulib
>    redefined already. */
> 
> so the whole point of it is to cancel a redefinition from the gnulib
> headers.  If it doesn't include the gnulib headers, there is no issue.
> The #undef free only affects the meaning of the symbol "free" used
> subsequently in the source file.  The binary objects compiled from
> gnulib code may have gnulib's redefinition of "free" (e.g. "rpl_free")
> but the code compiled from that particular file wouldn't reference it.
> Does that make sense?

It does.  This means that we can be sure to use a perl or gnulib version
if we call a function in libtexinfo (for gnulib only functions) or from
libtexinfoxs (perl only functions).

> It may or may not cause a problem depending on how allocated memory is
> passed between different parts of the code.  The use of strdup in
> convert/get_html_perl_info.c could potentially be problematic, depending
> on whether this is also redefined by Perl headers.
> 
> Here are some guidelines:
> 
> * The number of source files including Perl headers should be kept to
>   a minimum.

That's already the case. There is still room to separate codes more to
avoid gnulib headers included for the compilation of files including
Perl headers.  But it is not clear that it is the most important issue,
as discussed above.

> * In source files that include Perl headers, memory can be allocated with
>   "malloc", but needs to be freed with "free" in the same source file, and
>   not passed to code in other source files that might free it.  (It would
>   be possible to free it in code in other source files if those source files
>   also included the Perl headers, perhaps.)  Use of other heap allocation
>   functions, such as asprintf or strdup, need to be treated with caution,
>   especially if they may be overridden by gnulib, and may need to be
>   avoided.

Ok.

> * Likewise, code in source files that include Perl headers should not
>   attempt to free memory that was allocated in code in source files that
>   did _not_ include the Perl headers.

Ok.

> * Code in source files including Perl headers can still free memory by
>   calling helper functions defined in other source files - they just can't
>   call "free" directly.

Ok.

> As far as I remember, the reason for this requirement was that on
> MS-Windows (not sure if it's for other platforms too), the Perl headers
> redefine malloc and free.  If memory is allocated with non-redefined free,
> and then freed with redefined free (or vice versa), then an error occurs
> like "Free to wrong pool".
> 
> https://lists.gnu.org/archive/html/bug-texinfo/2016-01/msg00016.html
> https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00233.html

Thanks.

-- 
Pat