bug-texinfo
[Top][All Lists]
Advanced

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

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


From: Gavin Smith
Subject: Re: how to mix or avoid perl and gnulib headers and object files together?
Date: Sun, 3 Mar 2024 21:57:33 +0000

On Tue, Feb 27, 2024 at 10:38:37PM +0100, Patrice Dumas wrote:
> 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.

I've made some recent changes.

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

It would work by just using malloc instead of perl_only_malloc if the
source file included the Perl headers.  However, it is probably not a a
significant problem with the current usage of these functions.  I checked
this by running callgrind on "perl texi2any.pl --html" on an input file,
with TEXINFO_XS_CONVERT=1, and the perl_only_* functions were hardly
called (only once each, in fact).



reply via email to

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