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

[Gavin Smith]

On Fri, Feb 23, 2024 at 05:33:53PM +0100, Patrice Dumas wrote:
> Hello,
> 
> There are notes in C code warning against calling malloc or free and
> functions potentially redefined by gnulib in files which include the
> perl headers.  It may be related to the discussion here:
> 
> https://lists.gnu.org/archive/html/bug-texinfo/2022-10/msg00381.html
> 
> The NOTE is
>   /* NOTE: Do not call 'malloc' or 'free' in any function called in this file.
>      Since this file (build_perl_info.c) includes the Perl headers,
>      we get the Perl redefinitions, which we do not want, as we don't use
>      them throughout the rest of the program. */
> 
>   /* Can't use asprintf here, because it might come from Gnulib, and
>      will then use malloc that is different from Perl's malloc, whereas
>      free below is redirected to Perl's implementation.  This could
>      cause crashes if the two malloc/free implementations were different.  */
> 
> There have been lots of reorganization of C code and some of these
> issues may be obsolete, while new issues may have been introduced (by
> me).
> 
> 
> 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.

>  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?

(Incidentally I complained on the gnulib lists about the redefinition
of "free", but don't believe it ever stopped happening:
<https://lists.gnu.org/archive/html/bug-gnulib/2022-10/msg00036.html>.)

> This is the case of tp/Texinfo/XS/convert/main/build_perl_info.c, which
> is compiled and linked in libtexinfoxs.la, without any use of gnulib
> CPPFLAGS.  The compilation of the other library, libtexinfo.la uses
> gnulib.  Most XS objects link against both libtexinfoxs.la and
> libtexinfo.la.
> 
> 
> There are files which include the perl header and also include gnulib
> headers and call functions such as strndup or free, for example
> tp/Texinfo/XS/convert/build_html_perl_state.c
> tp/Texinfo/XS/convert/get_html_perl_info.c
> 
> Will this setup lead to problems?  I do not think that it is possible in
> general to avoid calling strdup/malloc/free in the file.  However it is
> possible to add #undef or use wrappers or segregate some code.

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.

* 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.

* 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.

* 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.

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


> 
> Any guidance of what should and shouldn't be done on that matter?
> 
> -- 
> Pat
>