Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain
| От | Bryan Green |
|---|---|
| Тема | Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain |
| Дата | |
| Msg-id | 26678db0-519e-4c77-9b34-c5f94f97f6b9@gmail.com обсуждение исходный текст |
| Ответ на | Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain (Thomas Munro <thomas.munro@gmail.com>) |
| Ответы |
Re: [PATCH] O_CLOEXEC not honored on Windows - handle inheritance chain
|
| Список | pgsql-hackers |
On 12/12/2025 9:57 PM, Thomas Munro wrote: > On Sat, Dec 13, 2025 at 3:44 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Thomas Munro <thomas.munro@gmail.com> writes: >>> Hearing nothing, pushed. >> >> fairywren is unimpressed: >> >> ../pgsql/src/test/modules/test_cloexec/test_cloexec.c: In function 'run_parent_tests': >> ../pgsql/src/test/modules/test_cloexec/test_cloexec.c:137:29: warning: unused variable 'space_pos' [-Wunused-variable] >> 137 | char *space_pos; >> | ^~~~~~~~~ > > The CI MinGW task also shows this warning, but it doesn't use -Werror. > The separate CompileWarnings task does, being its purpose, and it > includes a MinGW cross-build step, but that uses configure, and this > test is built only by meson. That wasn't a great idea... we knew we > were only dealing with Windows but forgot about MinGW, so I'll go and > write a patch to fix that aspect later today so we're covered for > warnings. I'll also think about whether it's worth checking for MinGW > warnings in both assert and non-assert builds (as we do for regular > Linux gcc/clang), and I'd also like to try to catch warnings from MSVC > and had an idea for how to do that... I might also try to think about > meson-vs-configure cross checks... > >> What is the point of that first snprintf(cmdline, ...), when its >> result is guaranteed to be overwritten just below? >> >> I'm also dubious about using MAX_PATH here; see the commentary >> about MAXPGPATH in pg_config_manual.h. Also, what's the point of >> using MAX_PATH when the result is going to be transferred into >> cmdline (with a hardwired size of 1024)? > > Fair points, I'll wait and see if Bryan is free to write a patch on > Monday (US), and otherwise write one myself. Thomas, A sanity check would be appreciated after the somewhat embarrassing sloppy code. I removed the useless snprintf() call that was using GetCommandLine(). That was left in place when I moved to GetModuleFileName(). Also, removed the unused 'space_pos' variable and the unneeded scope block. I decided to just use 1024 for the exe_path size since that is what cmdline is set to use. I also removed some self-evident comments that were leftover from my practice of writing comments and then coding. Apologies for the loss of time. Thanks, -- Bryan Green EDB: https://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: