|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Daniel Verite <daniel(at)manitou-mail(dot)org>|
|Subject:||Re: speed up unicode decomposition and recomposition|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Fri, Oct 23, 2020 at 04:18:13PM -0700, Mark Dilger wrote:
> On Oct 23, 2020, at 9:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?
|Next Message||Tom Lane||2020-10-24 00:04:35||Re: minor problem in boolean cast|
|Previous Message||Cary Huang||2020-10-23 23:56:58||minor problem in boolean cast|