Re: Fix C4819 warning in MSVC

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Fix C4819 warning in MSVC
Date: 2021-11-01 16:10:17
Message-ID: 156D04DA-B0BB-4DAF-9A94-B4E6F9442D30@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 1 Nov 2021, at 14:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>> Reading 1051867(dot)1635720347(at)sss(dot)pgh(dot)pa(dot)us I noticed that hamerkop raise a C4819
>> warning on brin_bloom.c, which is defined as:
>> "The file contains a character that cannot be represented in the current
>> code page (number). Save the file in Unicode format to prevent data loss."
>> The warning message is mostly gibberish but AFAICT the issue is that the
>> headercomment includes a citation to the paper used for the hashing scheme, in
>> which a footnote character has been copied from the paper (without the footnote
>> copied). Since the footnote is irrelevant for our documentation, I propose to
>> remove this offending character to remove warnings from the build.
>
> +1, but there are also C4819 warnings in fe_utils/print.c. Can we get
> rid of that too? That one's a bit more integral to the code, since
> (I think) it's complaining about the comments in the unicode_style table.
> But maybe we could replace those with Unicode codes + symbol names?

Aha, I missed that one when skimming the (quite chatty) log. The attached
addresses that file as well, replacing the comments with codepoints and names.
It does make the section of the code more verbose, but also more readable IMO.

--
Daniel Gustafsson https://vmware.com/

Attachment Content-Type Size
msvc_c4819.diff application/octet-stream 4.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-11-01 16:12:40 Re: Fix C4819 warning in MSVC
Previous Message Bossart, Nathan 2021-11-01 16:00:54 Re: inefficient loop in StandbyReleaseLockList()