From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: CI CompilerWarnings test fails on 15 in mingw_cross_warning |
Date: | 2024-11-18 11:09:26 |
Message-ID: | e8e646f5-8ffc-4639-b897-a9ecdccd34c3@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17.11.24 02:59, Andres Freund wrote:
> Hi,
>
> See https://cirrus-ci.com/task/5880116075560960
>
> [18:14:04.821] time make -s -j${BUILD_JOBS} world-bin
> [18:15:49.090] pg_locale.c: In function ‘get_collation_actual_version’:
> [18:15:49.090] pg_locale.c:1763:42: error: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long unsigned int’ [-Werror=format=]
> [18:15:49.090] 1763 | collversion = psprintf("%d.%d,%d.%d",
> [18:15:49.090] | ~^
> [18:15:49.090] | |
> [18:15:49.090] | int
> [18:15:49.090] | %ld
> [18:15:49.090] 1764 | (version.dwNLSVersion >> 8) & 0xFFFF,
> [18:15:49.090] | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [18:15:49.090] | |
> [18:15:49.090] | long unsigned int
>
> I have no idea why we are seeing this error now when we didn't in the past -
> there don't seem to have been any relevant changes?
>
> It does reproduce on my debian sid machine, so it's something we ought to fix,
> I think?
>
> We did fix it in newer versions:
>
> Author: Peter Eisentraut <peter(at)eisentraut(dot)org>
> Branch: master Release: REL_16_BR [a9bc04b21] 2023-03-24 07:21:40 +0100
>
> Fix incorrect format placeholders
>
> The fields of NLSVERSIONINFOEX are of type DWORD, which is unsigned
> long, so the results of the computations being printed are also of
> type unsigned long.
>
> Peter, any reason you didn't backpatch that?
The more interesting patch is 495ed0ef2d7, which did
- collversion = psprintf("%d.%d,%d.%d",
+ collversion = psprintf("%ld.%ld,%ld.%ld",
whereas my patch just did
- collversion = psprintf("%ld.%ld,%ld.%ld",
+ collversion = psprintf("%lu.%lu,%lu.%lu",
The former change was part of a larger patch, so it was not a candidate
for backpatching.
As to why it's happening now, the code in question is guarded by
#elif defined(WIN32) && _WIN32_WINNT >= 0x0600
so if it didn't happen before, maybe the _WIN32_WINNT value changed.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey M. Borodin | 2024-11-18 11:34:39 | Re: Using read_stream in index vacuum |
Previous Message | vignesh C | 2024-11-18 10:41:22 | Re: Improve the error message for logical replication of regular column to generated column. |