[PATCH 2/5] signal: Move sys_siglist to a compat symbol

Adhemerval Zanella adhemerval.zanella@linaro.org
Wed Apr 29 11:40:59 GMT 2020



On 29/04/2020 07:10, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> I see this in the mutt 1.13.2 sources:
>>>
>>> signal.c-73-/* Attempt to catch "ordinary" signals and shut down gracefully. */
>>> signal.c-74-static void exit_handler (int sig)
>>> signal.c-75-{
>>> signal.c-76-  curs_set (1);
>>> signal.c-77-  endwin (); /* just to be safe */
>>> signal.c-78-
>>> signal.c-79-  exit_print_string ("Caught signal ");
>>> signal.c-80-#if SYS_SIGLIST_DECLARED
>>> signal.c:81:  exit_print_string (sys_siglist[sig]);
>>> signal.c-82-#else
>>> signal.c-83-#if (__sun__ && __svr4__)
>>> signal.c:84:  exit_print_string (_sys_siglist[sig]);
>>> signal.c-85-#else
>>> signal.c-86-#if (__alpha && __osf__)
>>> signal.c:87:  exit_print_string (__sys_siglist[sig]);
>>> signal.c-88-#else
>>> signal.c-89-  exit_print_int (sig);
>>> signal.c-90-#endif
>>> signal.c-91-#endif
>>> signal.c-92-#endif
>>> signal.c-93-  exit_print_string ("...  Exiting.\n");
>>> signal.c-94-  exit (0);
>>> signal.c-95-}
>>
>> And on Linux it will be evaluated to:
>>
>>   static void exit_handler (int sig)
>>   {
>>     curs_set (1);
>>     endwin ();
>>
>>     exit_print_string ("Caught signal ");
>>   # 89 "../signal.c"
>>     exit_print_int (sig);
>>
>>
>>
>>     exit_print_string ("...  Exiting.\n");
>>     exit (0);
>>   }
>>
>> Since SYS_SIGLIST_DECLARED is not defined.  Not sure why exactly the
>> config is not setting it, since config.log does have
>> ac_cv_have_decl_sys_siglist=yes.
> 
> Huh, this is surprising.  Maybe this got fixed in neomutt?

No idea, I just downloaded the latest mutt code and try to build to
check its usage of the arrays. 

> 
>> And even its usage is not fully portable (solaris11 defines as
>> _sys_siglist, AIX 73 does not provide it). So I am not sure if we
>> should continue provide for newly binaries.
> 
> Another difference is that the variables are async-signal-safe.
> strerror and strsignal might not be if the argument is out of range
> (something that can be checked with the count variable in the other
> case).  At least our strsignal is already thread-safe.
> 

We have strerror_r at least as an extension.

> I'm going to propose errno_constant and signal_constant functions to
> cover the async-signal-safe case.  Let's see if they gain positive
> feedback from the larger libc community.

Instead I think it would be better just simplify glibc strerror
and strsignal assumptions to *not* return locale dependent messages
and add a strsignal_l for the case.

So strerror/strsignal will just directly access the underlying error
with the expected bound error checks and thus be asignal-safe.

> 
> I will review your patch some time later this week.
> 

Thanks.


More information about the Libc-alpha mailing list