On Fri, Feb 23, 2024 at 07:27:55PM +, 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
On Fri, Feb 23, 2024 at 07:27:55PM +, 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
On Sun, Feb 25, 2024 at 09:00:55PM +0100, Patrice Dumas wrote:
> On Sun, Feb 25, 2024 at 07:43:42PM +, Gavin Smith wrote:
> > It appears that there was no effort made to reset the counters at all.
> > If a parser run finished with one of the counters active, it would
> > remain active for the
On Sun, Feb 25, 2024 at 07:43:42PM +, Gavin Smith wrote:
> It appears that there was no effort made to reset the counters at all.
> If a parser run finished with one of the counters active, it would
> remain active for the next run.
Shouldn't there be an error message for the counters that
On Sun, Feb 25, 2024 at 07:01:22PM +, Gavin Smith wrote:
> So it appears there is a problem with the counter not being reset properly
> before the test runs, or sometime early on in the run.
>
> I'll try and do more investigation.
It appears that there was no effort made to reset the
On Sun, Feb 25, 2024 at 04:47:46PM +, Gavin Smith wrote:
> I occasionally get test failures in the
> "perl -w t/03coverage_braces.t definfoenclose_texinfo_commands" test,
> but cannot usually repeat it reliably. I suspect some issue with memory
> corruption or issue with uninitialised memory,
I occasionally get test failures in the
"perl -w t/03coverage_braces.t definfoenclose_texinfo_commands" test,
but cannot usually repeat it reliably. I suspect some issue with memory
corruption or issue with uninitialised memory, although I've not managed
to get anything to show up with valgrind
