The documentation for net:getaddrinfo defines the address_info type (Erlang -- net) as
address_info() =
#{family := socket:domain(),
socktype := socket:type(),
protocol := socket:protocol(),
address := socket:sockaddr()}
But alas that is not what I see coming out of OTP-24:
1> net:getaddrinfo("erlang.org").
{ok,[#{addr =>
#{addr => {192,121,151,106},family => inet,port => 0},
family => inet,protocol => udp,type => dgram},
#{addr =>
#{addr => {192,121,151,106},family => inet,port => 0},
family => inet,protocol => tcp,type => stream}]}
Shouldn’t the top level addr be address? And if so, would it make more sense to correct the docs or the implementation? (I assume the former)
3 Likes
This looks like a typo and a simple PR would take care of that 
Specifically, here is where this is put together, which references esock_atom_addr (declared globally in prim_socket_nif.c it looks like), thus address can never be returned unless that’s handled in prim_net (erl), but it is not.
The naming makes sense to me, being in line with POSIX. For posterity :
struct addrinfo {
int ai_flags; /* AI_PASSIVE, AI_CANONNAME, .. */
int ai_family; /* AF_xxx */
int ai_socktype; /* SOCK_xxx */
int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
socklen_t ai_addrlen; /* length of ai_addr */
char *ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr; /* binary address */
struct addrinfo *ai_next; /* next structure in linked list */
};
But a typo in the docs, right? I mean, changing the returned map might have serious consequences for users. (In AtomVM, we are returning a map with both addr and address, for OTP compatibility).
1 Like
Yes, I should have clarified that part It would definitely not be good to just go off and change the key
1 Like