I've done the same under cygwin _with_ X libraries. Don't see the first error, but I do see the second, plus another cygwin problem as related in http://list-archive.xemacs.org/xemacs-beta/200102/msg00481.html --with-gtk=no seems to work fine though. - Phil Bush, David writes:

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Agreed - on the 3 platforms I have everything runs except GTK + PDUMP, which I don't really know enough about to track down yet. Have to meditate on the resurrection functions for a weekend. What about this patch? I've never seen this, and http://list-archive.xemacs.org/xemacs-beta/200102/msg00481.html makes it seem like this isn't unique to the GTK-contaminated tree. -bp

Sandra> I got a --with-gdbtk=no build done on a Red Hat Linux 7.0 Sandra> on Alpha, but the --with-pdump --with-gdbtk=no failed. I Sandra> haven't figured out how to file a real build report yet. For successful builds, start the new xemacs and run M-x build-report. For failure builds, use an old xemacs, point the variables build-report-installation-file and build-report-make-output-files at the appropriate places, and run M-x build-report. --with-pdump on an Alpha? 64-bit issues, maybe? Can you also do that build with a gtk-clean (ie, standard 21.2.4x) tree? You can set your mail-user-agent if you want your familiar MUA environment. -- 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."

SJT> in regex.c is not platform-dependent, but others could be (eg, if I SJT> understand the symptoms correctly, the GCC distributed in Debian SJT> unstable changed from signed to unsigned size_t since last September). I don't believe you. I believe that on any platform where XEmacs is buildable, size_t and unsigned long are identical. Standard says: size_t which is the unsigned integer type of the result of the sizeof operator; and SJT> There have also been a couple of "XEmacs 21.2.4x spins its wheels SJT> uselessly" on xemacs-beta-ja (most recently a few minutes ago). SJT> So I don't think it is related to GTK, and I want to see how many of SJT> these go away after Ben's unsigned->signed changes get checked in. Will Ben's changes include replacing all uses of sizeof?

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.

Stephen J. Turnbull writes: Undestood. The reason I didn't do this is that is only possible for me to give meaninful f/b regarding gtk=no without manual intervention to work around my other problems. I'll submit a build report for those anyway. - Phil ------------------------------------------- Philip Aston - Senior Consultant BEA Professional Services (Northern Europe)