Re: How to read large numbers?
Hrvoje Niksic <hniksic(a)xemacs.org> writes:
[ I've Cc'ed Ben on this. Ben, please note the continuable
signal
related question at the end. ]
Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai writes:
> Tramp invokes `read' in a buffer containing an sexp which in turn
> might contain, as one item, a largish number. How do I make it so
> that the resulting Lisp structure contains -1 instead of that
> largish number?
Let me see if I understand this correctly. So, for instance, you have
a piece of buffer that looks like this:
(foo bar 1927120979049047309282389079128346218936)
Is it correct to say that you want to call (read (current-buffer)) and
have it return (foo bar -1)?
Well, "want to" might be a slight exaggeration ;-) In my copy of
Emacs, I see the following:
/----
| *** Welcome to IELM *** Type (describe-mode) for help.
| ELISP> (read "(foo bar 1927120979049047309282389079128346218936)")
| (foo bar -1)
\----
Also, the particular context is the Tramp handler for file-attributes.
It is supposed to return the user and group ids as numbers. One user
was reporting that he got a too-large number on some remote host. I
have some Perl code that gets executed on the remote host and more or
less directly prints the return value of file-attributes. Tramp just
`read's it from a temp buffer and returns it.
When I have questions what should happen, I usually look at Ange-FTP
because it is known to work. And there I see that the user and group
ids are returned as -1. So I thought that returning -1 would be the
right thing to do. And `read' already does that in Emacs, so I don't
have to do any additional work.
Your suggestion to trap the overflow and re-try seems to work, but
requires modifying the buffer.
Well, it's a temp buffer to begin with, so modifying the buffer is
not a problem. But I didn't get it to "work". Maybe I was just
looking at the wrong spot. I kind of expected point to advance to
the trouble spot when reading from the buffer, so it would have been
easy to modify the right spot in the buffer. But point didn't move.
I also didn't see another way to find out where the problem occurred.
Is there a way to figure that out?
One interesting feature that XEmacs supports are continuable errors.
Nice. But that will only work in a future XEmacs. If you have a
suggestion that will work with current XEmacs versions, that'd be
even greater.
FWIW, Richard is suggesting that I return the too-large user and
group ids as strings instead of numbers. But the device number is
already returned as a cons if it is too large, and I'm not sure it's
a good idea to have two different solutions for the same problem in
the (interface to) same function. So I'm trying to convince him to
adopt the cons approach.
I wonder what you folks think about this: if the user or group id is
too large to represented as an int, what should a filename handler
return?
kai
--
A large number of young women don't trust men with beards. (BFBS Radio)