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

[Patrice Dumas]

On Tue, Feb 27, 2024 at 08:10:31PM +0000, Gavin Smith wrote:
> On Mon, Feb 26, 2024 at 01:15:47AM +0100, Patrice Dumas wrote:
> > I did wrappers wrappers around functions to avoid mixing Perl and non-Perl
> > memory allocation related functions in commit
> 
> 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

No, and I am not sure that we can know beforehand if it is platform
dependent.

> implement these functions ourselves.  E.g., replace asprintf with
> malloc followed by sprintf, or strdup with malloc followed by memcpy.

I'll let you do that.

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

I am probably missing something, but this seems to undo the certainty that
the malloc function comes from a specific file, which includes specific
headers, as the malloc of the place where the macro is called would be
used, which could depend on where it is used.

-- 
Pat