|
Message-ID: <20191123174130.GI16318@brightrain.aerifal.cx> Date: Sat, 23 Nov 2019 12:41:30 -0500 From: Rich Felker <dalias@...c.org> To: Florian Weimer <fw@...eb.enyo.de> Cc: gilles@...lp.org, musl@...ts.openwall.com Subject: Re: freeaddrinfo() comments and questions On Sat, Nov 23, 2019 at 05:05:17PM +0100, Florian Weimer wrote: > * gilles: > > > In these other implementations, it is possible to write a custom > > struct addrinfo allocator and use freeaddrinfo() on it, just like it > > is possible to use getaddrinfo() and use a custom release function on > > it. This is not a very common use-case, granted, but it is one > > nonetheless, and one that works and has worked in a portable way for a > > long time across a wide variety of systems. > > I think this is clearly undefined. There is no way to know how > storage for ai_addr and ai_canonname is managed. These pointers could > point to separate allocations, made with malloc. They could be > interior pointers to the same top-level allocation at which start the > struct addrinfo object is allocated. Nothing even needs to use > malloc, including the outer struct addrinfo object. Indeed, this is absolutely undefined. Even the way the storage for the addrinfo structures themselves is allocated is unspecified. It need not be by malloc. For example if libc allowed malloc interposition, but only used the interposed functions itself for functions specified to return something allocated as if by malloc, and otherwise always used its internal malloc, then you would end up with a mix of structures allocated by different allocators, and passing one to the other's free would blow up. And of course they could be allocated by direct mmap, or from a static pool, or any of an unlimited number of other possible ways. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.