Why aren't we using strsignal(3) ?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Why aren't we using strsignal(3) ?
Дата
Msg-id 25758.1544983503@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Why aren't we using strsignal(3) ?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
While poking at the signal-reporting bug just pointed out by
Erik Rijkers, I couldn't help noticing how many places we have
that are doing some equivalent of this ugly dance:

#if defined(HAVE_DECL_SYS_SIGLIST) && HAVE_DECL_SYS_SIGLIST
    {
        char        str2[256];

        snprintf(str2, sizeof(str2), "%d: %s", WTERMSIG(exitstatus),
                 WTERMSIG(exitstatus) < NSIG ?
                 sys_siglist[WTERMSIG(exitstatus)] : "(unknown)");
        snprintf(str, sizeof(str),
                 _("child process was terminated by signal %s"), str2);
    }
#else
        snprintf(str, sizeof(str),
                 _("child process was terminated by signal %d"),
                 WTERMSIG(exitstatus));
#endif

(Plus, there's at least one place that *should* be doing this and is not.)

Not only is this repetitive and unreadable, but it's also obsolete:
at least as far back as POSIX:2008, there's a function strsignal()
that you're supposed to use instead.

I propose to replace all these places with code like

        snprintf(str, sizeof(str),
                 _("child process was terminated by signal %d: %s"),
                 WTERMSIG(exitstatus), pg_strsignal(WTERMSIG(exitstatus)));

where pg_strsignal is a trivial wrapper around strsignal() if that
exists, else it uses sys_siglist[] if that exists, else it just
returns "unrecognized signal".

            regards, tom lane


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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: select limit error in file_fdw