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

[Gavin Smith]

On Mon, Feb 26, 2024 at 01:15:47AM +0100, Patrice Dumas wrote:
> On Fri, Feb 23, 2024 at 07:27:55PM +0000, Gavin Smith wrote:
> > 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.
> 
> I did wrappers wrappers around functions to avoid mixing Perl and non-Perl
> memory allocation related functions in commit
> 
> https://git.savannah.gnu.org/cgit/texinfo.git/commit/?id=ba169cd7a8a8e67f280b305e19412fb63d23c71c
> 
> Hopefully it should solve this issue.
> 
> Do not hesitate to modify the comments for more clarity, especially in
> tp/Texinfo/XS/main/build_perl_info.c

I have a couple of queries about this:

* The comment in main/build_perl_info.c says that you can use a wrapper
perl_only_xasprintf to be sure that a Perl defined function is used.  This
refers to "vasprintf".  Did you check if Perl is actually guaranteed to
override vasprintf if it overrides malloc and new?  (Likewise for the
other perl_only_* functions.)  It could be more reliable to actually
implement these functions ourselves.  E.g., replace asprintf with
malloc followed by sprintf, or strdup with malloc followed by memcpy.

* Defining perl_only_* as wrappers in a different source file may make
it harder for the function calls to be inlined and optimised.  Could
using macros in header files be better, e.g. writing
"#define perl_only_malloc malloc"?  That is assuming that we need to
make it explicit that we intended to use any definition from the Perl
header files.