Re: expat parsing destructively?

Hi Nick,

IIRC I found cases where expat does not return copies of the buffer
which is being parsed.  (In past I tried to develop a parser that
did not copy any data to speed things up, but I could not achieve
it for the reasons below).

> -----Original Message-----
> From: Nick MacDonald nickmacd-at-gmail.com |Expat/1.0-Allow| 
> [mailto:...] 
> Sent: 29 October 2007 13:53
> To: Mark Williams
> Cc: [email protected]
> Subject: Re: [Expat-discuss] expat parsing destructively?
> 
> Mark:
> 
> You are of course absolutely correct in that regard... and I don't
> know what kind of internal memory management eXpat performs, so this
> may well be a very bad idea.  I do know, that in many cases, eXpat
> seems to return to you a copy of the same data it is parsing... I just
> don't know if it does that in all cases.  You could of course detect
> when the returned data did not reside within your supplied buffer,
> however its not quite clear to me what action you might take in such a
> case.
> 
> Nick
> 
> 
> On 29 Oct 2007 10:22:46 -0000, Mark 
> <[email protected]> wrote:
> > I think this is extremely unlikely this will work.  You are 
> assuming that expat will always return a pointer to the data 
> contained within the original memory buffer and not in any 
> internal buffers.
> >
> > ---- Original Message ----
> > Simply allocate 2 copies of the same data... i.e. read in 
> the data to
> > one buffer, malloc() another buffer the same size, and do a huge
> > memcpy() to make a duplicate copy.  Now let eXpat scan one copy, and
> > doing some quick and dirty pointer math, you can now find
> > corresponding locations in the "non-eXpat" buffer and destroy it to
> > your hearts content.  When you're all done, simply free 
> both buffers.
> > Its a little more memory intensive.. but sounds fairly 
> elegant to me,
> > and you don't need to worry about doing anything 
> unsupported by eXpat.
>