Re: temacs looping

mb> Standard says: SJT> Is there an URL for these standards? Or do I just have to use SJT> "klunker lookup" (say something sufficiently stupid -- it was, wasn't SJT> it? :-P -- so that Martin will have to correct me)? That's a pretty SJT> inefficient use of your time.... (But a more inefficient use of my SJT> money. ;-) The real standard costs time and money to get, so everyone uses a draft standard, which is good enough unless you're writing a compiler. http://anubis.dkuug.dk/jtc1/sc22/open/n2794/n2794.txt SJT> Anyway, all I knew was that the bug did not occur in the XEmacs SJT> 21.1.12 that I compiled in September, and did occur as soon as I SJT> switched to 21.2.42 compiled a couple of weeks ago. I'm 100% sure I SJT> saw a reference to (implicitly signed) long int wa-a-ay down there in SJT> /usr/lib/gcc-lib/i386-linux/2.9x.y/include/stddef.h. It was late and SJT> that file is a mare's-nest of #ifdef's, must have been ssize_t that SJT> was actually typedef'd there. (I don't have one of those handy, the SJT> gcc of that vintage I have is at home.) SJT> OK, so I jumped to conclusions; my bad. You're right, it has nothing SJT> to do with a change in size_t. An excerpt from SJT> cvs diff -r 1.12.2.1 src/lstream.h SJT> shows incautious removal of a "redundant" cast. :-( SJT> ＠＠ -347,7 +355,7 ＠＠ SJT> the attempt to write the data might have resulted in an SJT> EWOULDBLOCK error. */ SJT> return 0; SJT> - else if (num_written >= (int) lstr->out_buffer_ind) SJT> + else if (num_written >= lstr->out_buffer_ind) lstr-> out_buffer_ind = 0; SJT> else if (num_written > 0) SJT> { SJT> The cast is still there in 21.1.14. That's why 21.1.12 showed SJT> different behavior from 21.2.42. Yes, I was insufficiently careful making these changes. I'm not going to investigate right now, but the (int) cast is almost certainly also wrong, size-wise that is - it looks like it should be (ssize_t). Again, the use of `int' throughout the lstream code is incorrect. SJT> I think this goes to prove Ben's point. It's just too hard for even SJT> the best-informed programmers to always get those things right; why SJT> not make it easy by using signed types where they will do? Again, to eliminate use of unsigned types from the code, we have to consider every use of sizeof() a bug. Are we really prepared to do that kind of thing? I still feel very strongly that we should use unsigned types in the code for object sizes and element counts. Everytime I look at code using what I consider to be inappropriately signed types, I will want to rewrite it. At least the way I'm feeling right now, I can't bear the thought of maintaining the code using what I think are the wrong types. Sorry. I know Ben has the diametrically opposite opinion. There have been changes made that are far far more bug-injecting than use of signed/unsigned types. Mule is the most obvious example. I fixed a Mule bug last beta, and I'm sure there are others left in the code. Muleizing the source code involves a rewriting of the entire code base. Similarly for removing the use of unsigned types.