Discrepancy in type spec for net:getaddrinfo

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)


This looks like a typo and a simple PR would take care of that :slight_smile:

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 :slight_smile: It would definitely not be good to just go off and change the key :slight_smile:

1 Like