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
http://google.com/codesearch?q=file%3A%5C.el+%5C%28file-attributes
relies on this behaviour.
> Other than that, it seems a bad idea to couple
"large-file-ness" to
> 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
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches