I think I agree with Simon. If we want to implement "shreddable
buffers," it would have to be done in C, they would have to shred on
resize, and the XEmacs standard lstream I/O functions could not be
used. A "shredding lstream" type could be created, though.
>>>> "Matt" == Matt Tucker
<tuck(a)whistlingfish.net> writes:
Matt> (defun passwd-erase-buffer ()
Urk. Because the buffers are automatically resized by copying to a
newly malloc'd area, if .netrc is bigger than the default buffer size,
there may be several memory regions containing partial copies of
.netrc lying around. Furthermore there will definitely be Lstream
internal buffers containing parts of that file lying around. Since
those buffers default to 64kB IIRC, in fact they're likely to contain
the whole file.
Matt> I was wondering whether the following code could be used to
Matt> replace the while loop, although I expect the answer is
Matt> "no":
Matt> (insert (make-string s ?\000))
This should work just as well as long as a buffer resize is not
forced; it should basically amount to a memcpy followed by adjusting
the gap parameters. But if it forced a resize, then the buffer
containing the dangerous data would simply be abandoned, and the new
buffer overwritten with zeros. So what you would have to do would be
something like
(defun internal-buffer-size-list ()
"Return list of sizes at which buffer memory is reallocated in increasing
order; artificially starts with zero.")
(let ((l (internal-buffer-size-list)))
(while (< s (car l))
(setq l (cdr l))
(erase-buffer)
(insert (make-string (car l) ?\000))))
Obviously this could be optimized a little more. But it definitely
doesn't help at all with the problem of Lstream internal buffers
hanging around. And you'd have to be very careful to make sure that
list got initialized correctly; too small is not a problem, but too
big means the buffer will get abandoned before it's shredded.
I don't understand why the while loop takes very long, though. Unless
something very strange is going on, it seems rather unlikely that more
than one buffer resize should occur, meaning that
(insert ?\000)
(setq s (1- s))
should be very fast and constant time, as insertions are optimized to
take place at point.
Matt> Otherwise, does anyone have any ideas as to why this might
Matt> be taking so long?
Are you using Mule?
I don't see any reason why \000 should be special, but have you tried
with something else?
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."