Re: speed up unicode decomposition and recomposition - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: speed up unicode decomposition and recomposition
Date
Msg-id 20201024000252.GA5880@paquier.xyz
Whole thread Raw
In response to Re: speed up unicode decomposition and recomposition  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: speed up unicode decomposition and recomposition  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Oct 23, 2020 at 04:18:13PM -0700, Mark Dilger wrote:
> On Oct 23, 2020, at 9:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> genhtml: WARNING: function data mismatch at /home/postgres/pgsql/src/common/unicode_norm.c:102
>>
>> I've never seen anything like that before.  I suppose it means that
>> something about 783f0cc64 is a bit fishy, but I don't know what.
>>
>> The emitted coverage report looks fairly normal anyway.  It says
>> unicode_norm.c has zero test coverage, which is very possibly correct
>> since I wasn't running in UTF8 encoding, but I'm not entirely sure of
>> that either.
>
> I don't see it on mac nor on ubuntu64.  I get 70.6% coverage of
> lines and 90.9% of functions on ubuntu.

I can see the problem on Debian GID with lcov 1.14-2.  This points to
the second declaration of get_code_entry().  I think that genhtml,
because it considers the code of unicode_norm.c as a whole without its
CFLAGS, gets confused because it finds the same function to index as
defined twice.  It expects only one definition, hence the warning.  So
I think that this can lead to some incorrect data in the HTML report,
and the attached patch takes care of fixing that.  Tom, does it take
care of the issue on your side?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Cary Huang
Date:
Subject: minor problem in boolean cast
Next
From: Tom Lane
Date:
Subject: Re: minor problem in boolean cast