![](https://secure.gravatar.com/avatar/565476157eb3895a9c928ffce26d988d.jpg?s=120&d=mm&r=g)
Hi Martin,
The problem is not that re-allocation fails, the problem is that it succeeds.
Sometimes (usually?) this means that the base memory address changes, and any
pointers that have been 'sampled' using the old address have now suddenly become
invalidated. There's no easy way to trap an 'error' in that (not in C, at least).
Hartmut's patch in all likelyhood solves the entire issue: there are
not that many 'potentially problematic' variables in writet1.c, so the
chance that he missed one is quite slim.
But: the original code is not written in a particularly stuctured manner,
so it is quite important that all patches get tested thoroughly. I've looked
at it for only one hour, and that's just not enough for me to be confident
about the patch in the general case. It works for me, though. :-)
Greetings. Taco
On Sat, 11 Dec 2004 23:32:14 +0100
Martin Schröder
On 2004-12-11 17:15:32 +0100, Hartmut Henkel wrote:
What to do?
As you say: increase the buf size now, and fix the re-allocation in the next version. Can we replace the calls to re-allocation calls that will fail with an error message in the meantime?
Best regards Martin -- Martin Schröder, ms@artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de _______________________________________________ ntg-pdftex mailing list ntg-pdftex@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-pdftex