[resent to list]<br><br>I have a crazy-talk idea inspired by your question.<br><br>If your 
parser can take ownership of the lifetime of the XML data in memory then
 it might be possible to hack up the XML (by replacing the quotes at the
 end of strings with \0's, as an example) and then use it as a 
"pre-allocated" hunk of memory that already contains all your data; you 
just need to pull out the locations of this data (the attribs and tag 
data) and put them into pointers into the data structures that you're 
using to represent the XML tree.  It doesn't solve unwinding a failed 
alloc through a recursive call, but it makes the likelihood of an alloc 
failing as you'll only be alloc'ing the space to hold your XML node data
 structures which will only contain pointers and other scalars to 
describe the pointed-to data.<br>
<br>Does anyone want to contemplate the relationship between the size of
 an XML document and the equivalent representation in data structures + 
data that they point to?  I suspect that with 4/8 byte pointers pointing
 to everything vs. the verbosity of XML syntax it probably comes out 
close to even.  I ask because I wonder if one could reason about the 
maximum amount of memory required to store an arbitrary XML document of a
 given size.<br>
<br>BG<br><br><div class="gmail_quote">On Thu, Oct 6, 2011 at 2:54 PM, Daniel Burke <span dir="ltr"><<a href="mailto:dan.p.burke@gmail.com">dan.p.burke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm wondering what a commonly acceptable method of handling this failure would be, my Google-Fu's not giving me answers I like, so   I'm turning to the collective wisdom of this list. I suspect my knowledge of other languages is poisoning my thought process.<div>

<br></div><div>So parsing XML in a recursive function, with a structure that contains the relevant state of the task. My initial plan is to add a variable to the structure named "failed", and if an alloc fails I set it, and then test this after every function call that can fail, trying to bail out to the head function ASAP, where I call the free function on the partial tree I've created so far.</div>

<div><br></div><div>This puts a lot of ugly checking code in what is presently on the clean side of what I typically write. Most other languages I'd raise an exception and deal with the failure once.</div><div><br></div>

<div>I've a few existing Linux Kernel style Goto-Exceptions to keep all the error code together, and not spread throughout the meat of the functions, however my understanding is that it's a Bad Thing (tm) to goto across functions, as depending on compiler/flags there's going to have to be some stack twiddling, and while my inner assembly programmer says just store SI in the data structure, every other bone in my body is telling me this is a capitol offense.</div>

<div><br></div><div>Should I bite the bullet and turn my pretty 1 page function into a 3 page function with lots of checking, or is there a clever/easy way to quickly bail?<br><div><br></div><div><br></div><div>regards,<div>

<br></div><div>dan</div><div>--</div><font color="#888888"><div>"Within C++, there is a much smaller and cleaner language struggling to get out"</div><div>--Bjarne Stroustrup</div><br>
</font></div></div>
<br>_______________________________________________<br>
ccan mailing list<br>
<a href="mailto:ccan@lists.ozlabs.org">ccan@lists.ozlabs.org</a><br>
<a href="https://lists.ozlabs.org/listinfo/ccan" target="_blank">https://lists.ozlabs.org/listinfo/ccan</a><br>
<br></blockquote></div><br>