Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 01:38:57 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* pgstrsignal.c
|
|
|
|
* Identify a Unix signal number
|
|
|
|
*
|
|
|
|
* On platforms compliant with modern POSIX, this just wraps strsignal(3).
|
|
|
|
* Elsewhere, we do the best we can.
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 01:38:57 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
|
|
|
* src/port/pgstrsignal.c
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "c.h"
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* pg_strsignal
|
|
|
|
*
|
|
|
|
* Return a string identifying the given Unix signal number.
|
|
|
|
*
|
|
|
|
* The result is declared "const char *" because callers should not
|
|
|
|
* modify the string. Note, however, that POSIX does not promise that
|
|
|
|
* the string will remain valid across later calls to strsignal().
|
|
|
|
*
|
|
|
|
* This version guarantees to return a non-NULL pointer, although
|
2018-12-17 19:50:07 +01:00
|
|
|
* some platforms' versions of strsignal() reputedly do not.
|
2019-08-27 23:24:13 +02:00
|
|
|
*
|
|
|
|
* Note that the fallback cases just return constant strings such as
|
|
|
|
* "unrecognized signal". Project style is for callers to print the
|
|
|
|
* numeric signal value along with the result of this function, so
|
|
|
|
* there's no need to work harder than that.
|
Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 01:38:57 +01:00
|
|
|
*/
|
|
|
|
const char *
|
|
|
|
pg_strsignal(int signum)
|
|
|
|
{
|
|
|
|
const char *result;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have strsignal(3), use that --- but check its result for NULL.
|
|
|
|
*/
|
2018-12-17 19:50:07 +01:00
|
|
|
#ifdef HAVE_STRSIGNAL
|
Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 01:38:57 +01:00
|
|
|
result = strsignal(signum);
|
2019-08-27 23:24:13 +02:00
|
|
|
if (result == NULL)
|
|
|
|
result = "unrecognized signal";
|
2018-12-17 19:50:07 +01:00
|
|
|
#else
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We used to have code here to try to use sys_siglist[] if available.
|
|
|
|
* However, it seems that all platforms with sys_siglist[] have also had
|
|
|
|
* strsignal() for many years now, so that was just a waste of code.
|
|
|
|
*/
|
2019-08-27 23:24:13 +02:00
|
|
|
result = "(signal names not available on this platform)";
|
Modernize our code for looking up descriptive strings for Unix signals.
At least as far back as the 2008 spec, POSIX has defined strsignal(3)
for looking up descriptive strings for signal numbers. We hadn't gotten
the word though, and were still using the crufty old sys_siglist array,
which is in no standard even though most Unixen provide it.
Aside from not being formally standards-compliant, this was just plain
ugly because it involved #ifdef's at every place using the code.
To eliminate the #ifdef's, create a portability function pg_strsignal,
which wraps strsignal(3) if available and otherwise falls back to
sys_siglist[] if available. The set of Unixen with neither API is
probably empty these days, but on any platform with neither, you'll
just get "unrecognized signal". All extant callers print the numeric
signal number too, so no need to work harder than that.
Along the way, upgrade pg_basebackup's child-error-exit reporting
to match the rest of the system.
Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
2018-12-17 01:38:57 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|