database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-26 12:21:12 +03:00
Code Activity

Drop support for getting signal descriptions from sys_siglist[].

Browse Source 
It appears that all platforms that have sys_siglist[] also have
strsignal(), making that fallback case in pg_strsignal() dead code.
Getting rid of it allows dropping a configure test, which seems worth
more than providing textual signal descriptions on whatever platforms
might still hypothetically have use for the fallback case.

Discussion: https://postgr.es/m/25758.1544983503@sss.pgh.pa.us
This commit is contained in:
Tom Lane
2018-12-17 13:50:07 -05:00
parent ca4103025d
commit cc92cca431
4 changed files with 9 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
src/port/pgstrsignal.c
View File

@ -31,7 +31,7 @@
* the string will remain valid across later calls to strsignal().
*
* This version guarantees to return a non-NULL pointer, although
* some platforms' versions of strsignal() do not.
* some platforms' versions of strsignal() reputedly do not.
*/
const char *
pg_strsignal(int signum)
@ -40,21 +40,18 @@ pg_strsignal(int signum)
/*
* If we have strsignal(3), use that --- but check its result for NULL.
* Otherwise, if we have sys_siglist[], use that; just out of paranoia,
* check for NULL there too. (We assume there is no point in trying both
* APIs.)
*/
#if defined(HAVE_STRSIGNAL)
#ifdef HAVE_STRSIGNAL
result = strsignal(signum);
if (result)
return result;
#elif defined(HAVE_DECL_SYS_SIGLIST) && HAVE_DECL_SYS_SIGLIST
if (signum > 0 && signum < NSIG)
{
result = sys_siglist[signum];
if (result)
return result;
}
#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.
*/
#endif
/*