🚀 go-pugleaf

In article <445@usl.usl.edu>, pcb@usl.usl.edu (Peter C. Bahrs) writes:

# 3) Consider what happens in MS Windows when moving segments (i.e. pointers
# are changed, memory compacted, etc).  If your code is developed correctly
# everything is fine.
# So how are you doing IO???  Note that all of the C libraries are
# C libraries.  So if you call a stdio function, like scanf or printf and
# windows decides to move these routines, what happens.  Well apparently
# some of these routines use internall buffers and the pointers do not
# get updated like MS Windows pointers and ker-blang, fatal error of
# some kind. This 'syndrome' seems to occur with any C routine that may
# have pointers and especially when memory is low..

This problem arises when you try to use buffered I/O, and the C library 
code mallocs a buffer, which Windows translates to a LocalAlloc; Windows
may move your data segment under these conditions, invalidating any 
far pointers into it. 

A couple of work-arounds:

1.  Don't use buffered I/O (fopen, fwrite, etc), use the low-level
open, write, etc instead.  These are safe.  This means that you can't
use fprintf, but you can use sprintf to format a string into a buffer, 
then use write to write it to a file.

2.  Before doing any buffered I/O, use the Microsoft C Library's
setbuf() call to set up your own I/O buffer.  Then, the C library won't
try to malloc one, and the problem you mention will go away.

We've used both of these approaches with no problems, after having
lots of problems trying to do buffered I/O without the setbuf call.

3.  I haven't tried this, but Petzold describes some undocumented
Windows file I/O functions on pages 455-458 of _Programming Windows_.


-- 

---------
Matt Meighan
matt@nbires.nbi.com (nbires\!matt)