Jerry, I just tested the code I committed, and I find that when I pass an
long long (as off_t is declared as; eight bytes wide on 32-bit OS X) to
make_bignum, it gets truncated to a long--the most significant four bytes
are discarded. I can work around this, I suppose, checking the size of off_t
and masking and calling Flsh if necessary, but isn’t this a more general
issue with make_bignum?
Ar an chéad lá is fiche de mí Eanair, scríobh Stephen J. Turnbull:
Michael Sperber writes:
> Or (or (> size max-file-size) (eq size -1)), which actually seems
> reasonable to me.
I still don't like it; a file size of -1 makes it plain to everybody
that this file can't be handled by XEmacs.
We have START and END arguments to #'insert-file-contents, you know. I’ve
written Lisp code that uses them to deal with a file in chunks, and though
it’s not possible right now, it would actually be easy to modify the
implementation to deal with chunks of a “large” file at a time.
For context, GNU return a float if the size doesn’t fit in a Lisp integer.
Also for context, very little of the code at
relies on this behaviour.
> Other than that, it seems a bad idea to couple
> an arbitrary and not necessarily corresponding restriction in
> `file-attributes'. Rather, we should probably introduce a
> predicate `large-file-p' or `large-file-attributes-p'.
Agreed. I suspect that there are a half-dozen of issues like this
that we should identify (preferably resolve) before making any attempt
to support large files (even in `file-attributes').
That reads uncomfortably like “we must do everything before we do anything.”
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?
XEmacs-Patches mailing list