[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
