------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1424
Jeremy Harris <jgh146exb@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|tlyons@??? |jgh146exb@???
--- Comment #2 from Jeremy Harris <jgh146exb@???> 2015-03-29 15:34:43 ---
As of writing,
https://www.gnu.org/software/libc/manual/html_node/Host-Names.html#index-converting-host-address-to-name
... lists gethostbyname2() as AS-unsafe. getaddrinfo() is noted as another
possible means for getting the implementation, but there is no proper
definition
of it, let alone async-signal safety information. getipnodebyname() is
listed by Oracle
http://docs.oracle.com/cd/E36784_01/html/E36875/getipnodebyname-3socket.html
but does not specify signal-safety (either way). It was briefly present in
glibc, but then apparently deprecated in favour of getaddrinfo().
At least some implementations of getaddrinfo() are problematic:
http://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/
What a mess. It does feel like calling the acl_notquit processing from
within the signal-handler, local_scan_timeout_handler()/receive_bomb_out()
is a trifle ambitious. It's been like that since 2007 when this acl was added.
Back in the depths of Unix history this would have been a case for longjmp()
(the opinion was expressed once that there is about only one thing safe to
do in a signal handler: modify an int-sized flag). I wonder if this is still
the case.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
