www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Using gethostbyname_r instead of gethostbyname in std.socket

reply MWumpusZ <sinkhole01 bregalad.de> writes:
We are currently using phobos from 
http://downloads.dlang.org/releases/2016/dmd.2.071.0.linux.zip

Phobos' InternetAddress contained therein uses gethostbyname and 
not gethostbyname_r; std.socket imports core.sys.posix.netdb, 
which only makes gethostbyname available.

gethostbyname_r would be made available by importing 
std.c.linux.socket, but this is marked as deprecated in favour of 
core.sys.posix.BLAH

The use of gethostbyname is a problem for us because, even though 
std.socket synchronises access to the function, we are using a 
third party (non-D) library in our application which also uses 
gethostbyname, and of course that library doesn't care about the 
synchronisation in std.socket.


Is there a reason why gethostbyname_r isn't usually used?
Even for those environments which don't have it, version(linux) 
(or whatever) in core.sys.posix.netdb should be able to deal with 
that easily, shouldn't it?
Oct 07 2016
parent reply Jakob Ovrum <jakobovrum gmail.com> writes:
On Friday, 7 October 2016 at 08:38:24 UTC, MWumpusZ wrote:
 We are currently using phobos from 
 http://downloads.dlang.org/releases/2016/dmd.2.071.0.linux.zip

 Phobos' InternetAddress contained therein uses gethostbyname 
 and not gethostbyname_r; std.socket imports 
 core.sys.posix.netdb, which only makes gethostbyname available.

 gethostbyname_r would be made available by importing 
 std.c.linux.socket, but this is marked as deprecated in favour 
 of core.sys.posix.BLAH

 The use of gethostbyname is a problem for us because, even 
 though std.socket synchronises access to the function, we are 
 using a third party (non-D) library in our application which 
 also uses gethostbyname, and of course that library doesn't 
 care about the synchronisation in std.socket.


 Is there a reason why gethostbyname_r isn't usually used?
 Even for those environments which don't have it, version(linux) 
 (or whatever) in core.sys.posix.netdb should be able to deal 
 with that easily, shouldn't it?
gethostbyname_r is a GNU extension and not standard POSIX. That means it's only available on GNU/Linux systems that additionally don't use an alternative libc. gettaddrinfo is a more recent standard reentrant function with more functionality. InternetHost.getHostByName uses gethostbyname_r if visible and otherwise falls back to gethostbyname. There doesn't appear to be a condition in which gethostbyname_r would be visible, probably as a result of moving from std.c.linux to core.sys.posix. InternetHost.getHostByName is public so it can be used directly, but apart from that it appears to be used internally twice: 1) in getAddress when getaddrinfo is not available. 1) always used in the constructor of InternetAddress. I guess #2 is the issue you're having. The doc for InternetAddress does say it uses InternetHost internally, and the docs do recommend getAddress over using Internet{Host, Address} directly, but maybe InternetHost.getHostByName should use getAddress internally to benefit from getaddrinfo. If not, it should probably at least warn about not being reentrant. I don't know what OS still doesn't have getaddrinfo. Ideally we could deprecate all these bad legacy types and functions.
Oct 08 2016
parent MWumpusZ <sinkhole01 bregalad.de> writes:
On Saturday, 8 October 2016 at 13:46:28 UTC, Jakob Ovrum wrote:
...
 The doc for InternetAddress does say it uses InternetHost 
 internally, and the docs do recommend getAddress over using 
 Internet{Host, Address} directly,
I have no idea why we don't use std.socket.getAddress; I'll look into that. If switching over is viable (which I imagine it is) and sufficient, then that sounds like a great solution short term.
 but maybe InternetHost.getHostByName should use getAddress 
 internally to benefit from getaddrinfo.
Sounds good :) I can't comment on what wider impact that might have though.
 If not, it should probably at least warn about not being 
 reentrant.
It is "kind of" reentrant - it has synchronisation around the gethostbyname call. Things fall apart when gethostbyname is accessed directly, e.g. by a third party library, as is the case in our application.
Oct 10 2016