Re: speed up unicode decomposition and recomposition

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: speed up unicode decomposition and recomposition
Дата
Msg-id 20201024000252.GA5880@paquier.xyz
обсуждение исходный текст
Ответ на Re: speed up unicode decomposition and recomposition  (Mark Dilger <mark.dilger@enterprisedb.com>)
Ответы Re: speed up unicode decomposition and recomposition  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Cary Huang
Дата:
Сообщение: minor problem in boolean cast
Следующее
От: Tom Lane
Дата:
Сообщение: Re: minor problem in boolean cast