ISOLATED, can't grok: 21.2 Showstopper? BAD DATA LOSS on disk full

sjt> So I tried again in more controlled circumstances, saved a sjt> file to a full disk, got no error, and yes, it was truncated. sjt> Did it again, XEmacs wrote zero of 1024*1024 bytes to disk, sjt> and reported success. No signal. GCC silliness? This code has been working for at least two years. It hasn't been touched AFAICT with cvs annotate. bash-2.04$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.3/specs gcc version 2.95.3 20010125 (prerelease) Note that num_written is locally declared ssize_t (int), and lstr->out_buffer_ind is size_t (unsigned long int? the definition of size_t is buried in /usr/lib/gcc-lib/i386-linux/2.95.3/include/stddef.h in about 50 nested #ifdefs HATE GCC HATE HATE 'scuse me): Lstream_flush_out (lstr=0x84c44f8) at /coda/Projects/XEmacs/21.2-HEAD/src/lstream.c:350 350 if (num_written == 0) (gdb) print num_written $24 = -1 (gdb) print lstr->out_buffer_ind $25 = 63 (gdb) step 356 else if (num_written >= lstr->out_buffer_ind) (gdb) 357 lstr->out_buffer_ind = 0; (gdb) print (num_written >= lstr->out_buffer_ind) $26 = 1 (gdb) print (num_written >= (int) lstr->out_buffer_ind) $27 = 0 (gdb) Aaaaarggggh! The following patch fixes this particular problem, but which of the other size_t members should be ssize_t?. (The funky -U 14 is to catch the whole struct.) What other bad things have happened? Index: src/lstream.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/lstream.h,v retrieving revision 1.5.2.9 diff -u -U14 -r1.5.2.9 lstream.h --- lstream.h 2001/01/23 04:42:05 1.5.2.9 +++ lstream.h 2001/02/15 12:06:51 ＠＠ -145,29 +145,30 ＠＠ struct lstream { struct lcrecord_header header; const Lstream_implementation *imp; /* methods for this stream */ Lstream_buffering buffering; /* type of buffering in use */ size_t buffering_size; /* number of bytes buffered */ unsigned char *in_buffer; /* holds characters read from stream end */ size_t in_buffer_size; /* allocated size of buffer */ size_t in_buffer_current; /* number of characters in buffer */ size_t in_buffer_ind; /* pointer to next character to take from buffer */ unsigned char *out_buffer; /* holds characters to write to stream end */ size_t out_buffer_size; /* allocated size of buffer */ - size_t out_buffer_ind; /* pointer to next buffer spot to write a character */ + ssize_t out_buffer_ind; /* pointer to next buffer spot to write a character + gets compared to error returns, must be signed */ /* The unget buffer is more or less a stack -- things get pushed onto the end and read back from the end. Lstream_read() basically reads backwards from the end to get stuff; Lstream_unread() similarly has to push the data on backwards. */ unsigned char *unget_buffer; /* holds characters pushed back onto input */ size_t unget_buffer_size; /* allocated size of buffer */ size_t unget_buffer_ind; /* pointer to next buffer spot to write a character */ size_t byte_count; int flags; max_align_t data[1]; }; -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."