Re: temacs looping

mb> Standard says: Is there an URL for these standards? Or do I just have to use "klunker lookup" (say something sufficiently stupid -- it was, wasn't it? :-P -- so that Martin will have to correct me)? That's a pretty inefficient use of your time.... (But a more inefficient use of my money. ;-) Anyway, all I knew was that the bug did not occur in the XEmacs 21.1.12 that I compiled in September, and did occur as soon as I switched to 21.2.42 compiled a couple of weeks ago. I'm 100% sure I saw a reference to (implicitly signed) long int wa-a-ay down there in /usr/lib/gcc-lib/i386-linux/2.9x.y/include/stddef.h. It was late and that file is a mare's-nest of #ifdef's, must have been ssize_t that was actually typedef'd there. (I don't have one of those handy, the gcc of that vintage I have is at home.) OK, so I jumped to conclusions; my bad. You're right, it has nothing to do with a change in size_t. An excerpt from cvs diff -r 1.12.2.1 src/lstream.h shows incautious removal of a "redundant" cast. :-( ＠＠ -347,7 +355,7 ＠＠ the attempt to write the data might have resulted in an EWOULDBLOCK error. */ return 0; - else if (num_written >= (int) lstr->out_buffer_ind) + else if (num_written >= lstr->out_buffer_ind) lstr->out_buffer_ind = 0; else if (num_written > 0) { The cast is still there in 21.1.14. That's why 21.1.12 showed different behavior from 21.2.42. I think this goes to prove Ben's point. It's just too hard for even the best-informed programmers to always get those things right; why not make it easy by using signed types where they will do? -- 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."