outdated url-library: is XEmacs still the next generation of Emacs?

[Stephen J. Turnbull]

Aidan Kehoe writes:

 > (while (not (eq (point) (point-max)))
 >   ...)

Which is bad style anyway, it should be "=".

 > needs to become 
 > 
 > (while (not (eql (point) (point-max)))
 >   ...)
 > 
 > (but we can have the byte-compiler check for that, plus, maybe, the

Yes.

 > pseudo-Ebola stuff I mentioned) and will generate a lot of immediately
 > garbage bignums. But if you *want* to deal with files that big in XEmacs,
 > you probably have lots of memory (in which case we really should increase
 > gc-cons-threshold appreciably at startup) or are working noninteractively,
 > so garbage collection isn’t as annoying as it otherwise might be.

Yes, agreed.  That's my rationale for suggesting it, too.  However,
you can't increase the threshold indefinitely, because even on a
4-cylinder 2.4GHz Opteron box GC can make XEmacs drop dead for seconds
with current default settings.  `point' is called a lot, but
`point-max' I think is much less frequent than `point-min'.

 >  >  > it’s eminently reasonable, and shouldn’t be too much work. (I’m
 >  >  > thinking, move the Charbpos, Bytebpos and Membpos typedefs to
 >  >  > corresponding to off_t rather than EMACS_INT;
 >  > 
 >  > I don't understand that.  off_t is likely to be 32 bits on 32-bit
 >  > platforms.
 > 
 > Not on 32-bit platforms with large file support. Though as I understand it,
 > large file support on Linux is a bit of a red-headed stepchild, it needs
 > special compile time defines.

Exactly.  And AIUI the underlying kernel calls are different (ie, you
can choose at runtime whether you want a large file version or not).
Apple at least supports off64_t (or whatever it is) though, so
probably there's a standard typedef for this.

Basically your strategy makes explicit what I was thinking, I was just
confused by your choice of off_t here.  We need to be careful about
that.  If there is a standard typedef that makes it explicit that
"this supports large file sizes and offsets", we should use that,
otherwise we should use something like EMACS_OFF64_T (or maybe just
EMACS_OFFSET).

However, note that if a (void *) is 32 bits, all we get out of this is
a (maximum) of a 4GB file anyway, since that's an absolute upper bound
on buffer size.  Properly warning the users of such systems when
attempting to access such files will be important.