4:53 p.m.
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?
Hm. Maybe I need to invoke kill-sexp at point, then insert -1, then
go back to the beginning and try again. Is this right?
kai
--
A large number of young women don't trust men with beards. (BFBS Radio)
11:44 p.m.
[ 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)?
Your suggestion to trap the overflow and re-try seems to work, but
requires modifying the buffer. If this is not allowed, you must
create a temporary buffer, which is slower. You could optimize by
trying to read from the buffer in-place, and if that fails, copy the
expression in a temporary buffer and continue from there, replacing
the overflowing constants with -1. This is not hard to do, but it's
tedious.
One interesting feature that XEmacs supports are continuable errors.
This means that you should be able to use a condition-case-like a
handler that returns from a new value, in your case -1. You can test
this from the debugger: set debug-on-error to t, evaluate
(read (current-buffer)) before the above sexp, and press `r -1 RET'
in the debugger. The returned value will be the desired (foo bar -1).
However, this feature currently only works from the debugger. The way
to code it would be like this:
(defun read-trapping-overflow ()
(call-with-condition-handler
(lambda (error-info)
;; Correct code would check whether the error really is integer
;; overflow and rethrow by returning `signal' if not.
;; Otherwise, replace overflowing value with -1.
-1)
(lambda ()
(read (current-buffer)))))
But for this to work, you need to enable that functionality with this
patch:
--- src/eval.c.orig Mon Jul 29 00:27:19 2002
+++ src/eval.c Mon Jul 29 00:41:48 2002
＠＠ -1928,12 +1928,12 ＠＠
NNUNGCPRO;
}
NUNGCPRO;
-#if 0
- if (!EQ (tem, Qsignal))
- return return_from_signal (tem);
-#endif
+
/* If handler didn't throw, try another handler */
Vcondition_handlers = all_handlers;
+
+ if (!EQ (tem, Qsignal))
+ return return_from_signal (tem);
}
/* It's a condition-case handler */
I have no idea why someone went to all the trouble to implement the
continuable errors, and then disabled their use! If the feature is
disabled because it's unstable, then why is it available from the
debugger?
Ben, can you comment on this? Does this patch clash with your
modified `signal' workspace?
Unless there is a good reason to disable this, I'd like this patch to
be applied.
8:55 a.m.
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)
3:03 p.m.
Kai.Grossjohann(a)CS.Uni-Dortmund.DE (Kai writes:
> 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 ;-)
Why?
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)
\----
Truncating large numbers into -1 looks like a bug to me, albeit a
convenient one in this case.
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.
[...]
FWIW, Richard is suggesting that I return the too-large user and
group ids as strings instead of numbers.
Richard is right. That's what I would do. Another way is to slap a
.0 and turn them into floating point. How well that works for you
depends on the range of numbers you have to be able to handle.
And `read' already does that in Emacs, so I don't have to do
any
additional work.
No additional work, but only depending on whether you want to support
XEmacs or not. I'm convinced that throwing an exception in face of
overflowing input is better than silent truncation. And even if it
weren't, it is my understanding that you want to support the current
versions of XEmacs.
> 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".
Here's a version that works (for me):
(defun read-ignoring-overflow ()
(let ((done nil)
(startpos (point))
result)
(while (not done)
(setq done t)
(condition-case err
(setq result (read (current-buffer)))
(invalid-read-syntax
(message "%s" err)
(unless (string-match "integer constant overflow" (cadr err))
;; If this is not an overflow error, resignal it.
(signal (car err) (cdr err)))
(setq done nil)
;; Replace the sexp before point with -1 and retry.
(kill-sexp -1)
(insert "-1")
(goto-char startpos))))
result))
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.
The point moves for me, to the position right after the trouble spot.
But relying on that is usually not a good idea, which is why the
solution with continuable errors is the correct one. It's a shame we
can't use it.
> 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.
See if the above works on the XEmacs you have. I think it should work
on XEmacsen since at least 19.12.
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?
Please let's not go the cons route one more time -- it's a gross hack.
Use either floating point (if you're sure it won't overflow as well)
or a string. I'd use a string.
7948
days inactive
7950
days old
3 comments
2 participants
participants (2)
-
Hrvoje Niksic -
Kai Großjohann