Export buffers borking?

[Fairlight]

On Sat, Sep 08, 2007 at 12:41:03AM -0400, Kenneth Brody, the prominent pundit,
witicized:
> If you have an uncast dummy field, and keep appending to it so that the
> length would exceed 32,767 characters, it will crash with an out-of-memory
> error.

Except that in the interests of accuracy in error reporting, that's not
actually a true statement--that it's out of memory.  It's unwilling to
allocate more memory to it, but it does not mean you're actually out of
memory.

I've run into a similar situation with a photo panorama maker.  I threw
some really high-res images at it (about 38) and they were at the native
ungodly size, and if I tried to crank the end export resolution of the
QuickTime VR movie up even close to what it said optimal was, it would say
I did not have enough memory or disk space.  I checked with Isarn TaskInfo,
and I never exceeded 1GB out of 2GB RAM, and I had 29GB free on the
smallest of three segments (the other two drives had 125GB or so free each,
but the C drive is what my pagefile is on, so I used that as my test).
Disk space was never used either, as I repeatedly checked as it worked.

I really hate it when programs don't actually say what they mean.  It's
-not- out of memory.  There's plenty of memory left.  It's a buffer
overflow condition--albeit one that's handled gracefully and NOT the
security-type buggy one.

You see "out of memory", you start looking at a far different set of
potential remedies than you do if you see another message.  People start
closing apps, trying to free memory, etc.  None of which will have the
least bit of actual impact on the condition.  All because some program
somewhere wouldn't deign to use more than 32KB for a buffer, and then
wouldn't report the problem accurately.  I call that sending the user on a
time-wasting wild goose chase.

mark->
-- 
The latest synth mixdown...
http://media.fairlite.com/Isolation_Voiceless_Cry_Mix.mp3