title: _Expand versus new versus GNU
body: <p>Recently, I made a new friend.  His name is <a href="http://msdn.microsoft.com/en-us/library/wfzt8b7y.aspx" rel="noreferrer">_expand</a>, and we've had some nice conversations, and I've even hung out with him a few times.  But when I started asking around, no one had ever heard of my _expand.  I became suspicious.  I called a few thoroughly non-metaphorical friends at microsoft, and a few friends elsewhere in the business.  Nothing.  No one had ever used it.  I noodled around various search engines and source trees.  Nothing except a cursory mention here and there.  Certainly not enough information on performance and compatibility for me to introduce _expand into production code or more pertinently, generic libraries.  </p>
  
  <p>Worse, there's no equivalent function that I can find in any of the gnu libraries, so anything I hack up with my new friend isn't going to be portable in the least.  Which is a shame, because it's really a fascinating and exciting capacity to have.  Certainly, I could dig down into realloc, and pull apart how it functions, but the problem there is that much of the implementation is highly variable on *nixes.  So I'd have to code version after version to try and get a portable _expand.  Still, it seems ridiculous that nothing similar exists in the glib or the expanded gnu libs.  </p>
  
  <ol>
  <li>Is there a similar function that I should know about for linux hacking?  <strong>Mostly Answered</strong></li>
  <li>Is there a standard hook that I could build a similar function on?  <strong>Answered</strong></li>
  <li>Does anyone know what kind of performance _expand offers?  </li>
  <li>How does it interact with objects allocated on the LFH?</li>
  </ol>
  
  <p>To clarify my interests, I'm trying to build a singly-linked accumulator that expands in an attempt to minimize fragmentation while allocating multiple-element blocks along the lines of the traditional deque implementation.  By constraining the use-cases for element addition and deletion, I'm hoping to optimize time-to-delete for the whole structure, as well as element insertion and indexing.  As a result, the "loud failure" of _expand lets me make the structure think intelligently about when and if it can resize inplace, and what that means about where it can put data.</p>