Re: Make all Perl warnings fatal
От | Andrew Dunstan |
---|---|
Тема | Re: Make all Perl warnings fatal |
Дата | |
Msg-id | f51095ea-6f4f-b6fe-e260-f697260b0bff@dunslane.net обсуждение исходный текст |
Ответ на | Re: Make all Perl warnings fatal (Michael Paquier <michael@paquier.xyz>) |
Список | pgsql-hackers |
On 2023-08-22 Tu 00:05, Michael Paquier wrote:
On Mon, Aug 21, 2023 at 11:51:24AM -0400, Andrew Dunstan wrote:It's not really the same as -Werror, because many warnings can be generated at runtime rather than compile-time. Still, I guess that might not matter too much since apart from plperl we only use perl for building / testing.However, is it possible to trust the out-of-core perl modules posted on CPAN, assuming that these will never produce warnings? I've never seen any issues with IPC::Run in these last years, so perhaps that's OK in the long-run.
If we do find any such issues then warnings can be turned off locally. We already do that in several places.
Regarding the dangers mentioned, I guess we can undo it if it proves a nuisance.Yeah. I am wondering what the buildfarm would say with this change.+1 to getting rid if the unnecessary call to getprotobyname().Looking around here.. https://perldoc.perl.org/perlipc#Sockets%3A-Client%2FServer-Communication Hmm. Are you sure that this is OK even in the case where the TAP tests run on Windows without unix-domain socket support? The CI runs on Windows, but always with unix domain sockets around as far as I know.
The socket call in question is for a PF_INET socket, so this has nothing at all to do with unix domain sockets. See the man page for socket() (2) for an explanation of why 0 is ok in this case. (There's only one protocol that matches the rest of the parameters).
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: