GNU bug report logs - #56773
29.0.50; (readablep UNREADABLE) causes strange things

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56773 in the body.
You can then email your comments to 56773 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Tue, 26 Jul 2022 05:42:05 +0200

Hello,

emacs -Q:

(progn (readablep (current-window-configuration))
       (current-buffer))
==> #<buffer  prin1>

After evaluating such a `readablep' call, weird things can happen
because of this buffer being current.  I tried to actually display that
buffer and the window I got looked quite funny, one second later Emacs
had crashed.

TIA,

Michael.


In GNU Emacs 29.0.50 (build 31, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2022-07-26 built on drachen
Repository revision: c455023f93f5073e7032a2097821e23eafa6f1aa
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Message #8 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Tue, 26 Jul 2022 14:31:19 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> (progn (readablep (current-window-configuration))
>        (current-buffer))
> ==> #<buffer  prin1>
>
> After evaluating such a `readablep' call, weird things can happen
> because of this buffer being current.  I tried to actually display that
> buffer and the window I got looked quite funny, one second later Emacs
> had crashed.

Oops.

The problem is trivial to fix in `unreadablep' (just smack a
`save-excursion' in there), but I think this should be fixed in a better
way.  The problem is that PRINTPREPARE sets the current buffer to the
super-duper secret buffer Vprin1_to_string_buffer (i.e., " prin1"), and
we should restore the real buffer before calling
`print-unreadable-function' in `print_vectorlike'.

But which buffer that was doesn't seem to be available at that point --
it's just stored in

#define PRINTPREPARE							\
   struct buffer *old = current_buffer;					\

So we'd need to store that in a way we can access it later, but I'm not
sure where/how it'd make the most sense to do so...  Any ideas?

Meanwhile I've pushed a failing test for this to the trunk.

Message #13 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: michael_heerdegen <at> web.de, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Tue, 26 Jul 2022 15:39:53 +0300

> Cc: 56773 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Tue, 26 Jul 2022 14:31:19 +0200
> 
> So we'd need to store that in a way we can access it later, but I'm not
> sure where/how it'd make the most sense to do so...  Any ideas?

unwind_protect?

Message #16 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Tue, 26 Jul 2022 14:44:31 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> unwind_protect?

Where would the unwind_protect be?

The problem is here:

  if (!NILP (Vprint_unreadable_function)
      && FUNCTIONP (Vprint_unreadable_function))
    {
      specpdl_ref count = SPECPDL_INDEX ();
      /* Bind `print-unreadable-function' to nil to avoid accidental
	 infinite recursion in the function called.  */
      Lisp_Object func = Vprint_unreadable_function;
      specbind (Qprint_unreadable_function, Qnil);
      Lisp_Object result = CALLN (Ffuncall, func, obj,
				  escapeflag? Qt: Qnil);

We need to switch back to the original buffer before that Ffuncall, but
we don't know what the original function was -- it's just stored in a
local variable in prin1(-to-string).

Message #19 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: michael_heerdegen <at> web.de, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Tue, 26 Jul 2022 16:12:11 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: michael_heerdegen <at> web.de,  56773 <at> debbugs.gnu.org
> Date: Tue, 26 Jul 2022 14:44:31 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > unwind_protect?
> 
> Where would the unwind_protect be?
> 
> The problem is here:
> 
>   if (!NILP (Vprint_unreadable_function)
>       && FUNCTIONP (Vprint_unreadable_function))
>     {
>       specpdl_ref count = SPECPDL_INDEX ();
>       /* Bind `print-unreadable-function' to nil to avoid accidental
> 	 infinite recursion in the function called.  */
>       Lisp_Object func = Vprint_unreadable_function;
>       specbind (Qprint_unreadable_function, Qnil);
>       Lisp_Object result = CALLN (Ffuncall, func, obj,
> 				  escapeflag? Qt: Qnil);
> 
> We need to switch back to the original buffer before that Ffuncall, but
> we don't know what the original function was -- it's just stored in a
> local variable in prin1(-to-string).

I'm confused: "original function" or "original buffer"?

The original buffer is given by current_buffer before you call the
function which could change that, and the unwind_protect call should
be before calling that function.

But you already know all that, so I'm afraid I'm missing something
here.

Message #22 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Tue, 26 Jul 2022 15:24:22 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> I'm confused: "original function" or "original buffer"?

Original buffer.

> The original buffer is given by current_buffer before you call the
> function which could change that, and the unwind_protect call should
> be before calling that function.
>
> But you already know all that, so I'm afraid I'm missing something
> here.

Yes -- look at the call sequence from prin1-to-string and down to where
we're calling the function.  The buffer that was current when
prin1-to-string was called is not available from print_vectorlike, as
far as I can see.

Message #25 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Wed, 27 Jul 2022 11:30:13 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Yes -- look at the call sequence from prin1-to-string and down to where
> we're calling the function.  The buffer that was current when
> prin1-to-string was called is not available from print_vectorlike, as
> far as I can see.

That is -- there's two things that have to be fixed.  The first thing
(which I was talking about here) is that the current_buffer has to be
made available way down in print_vectorlike, so that we don't call the
callback from the " prin1" buffer, because that's really confusing.  I
think we can accomplish that by specbinding some variable in
PRINTPREPARE.

The other thing is that we have to ensure that the stuff in PRINTFINISH
is actually done when we have a non-local exit, and putting that stuff
in an unwind_protect should fix that.  I.e., PRINTPREPARE sets up the
unwind_protect, of course.

And when doing that, we might as well get rid of the macros altogether
and do this more traditionally via functions.

Does anybody see any obvious disadvantages to doing it this way?  I
guess it could potentially make calls to `prin1' (etc) slower, but I
don't know whether that'd be noticeable.

Message #28 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Wed, 27 Jul 2022 17:41:12 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> unwind_protect?
>
> Where would the unwind_protect be?
>
> The problem is here:
>
>   if (!NILP (Vprint_unreadable_function)
>       && FUNCTIONP (Vprint_unreadable_function))
>     {
>       specpdl_ref count = SPECPDL_INDEX ();
>       /* Bind `print-unreadable-function' to nil to avoid accidental
> 	 infinite recursion in the function called.  */
>       Lisp_Object func = Vprint_unreadable_function;
>       specbind (Qprint_unreadable_function, Qnil);
>       Lisp_Object result = CALLN (Ffuncall, func, obj,
> 				  escapeflag? Qt: Qnil);
>
> We need to switch back to the original buffer before that Ffuncall, but
> we don't know what the original function was -- it's just stored in a
> local variable in prin1(-to-string).

Isn't that problem already present?  IOW, that function is still called
in the internal buffer under the current code.

Message #31 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Wed, 27 Jul 2022 17:41:30 +0800

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Hello,
>
> emacs -Q:
>
> (progn (readablep (current-window-configuration))
>        (current-buffer))
> ==> #<buffer  prin1>
>
> After evaluating such a `readablep' call, weird things can happen
> because of this buffer being current.  I tried to actually display that
> buffer and the window I got looked quite funny, one second later Emacs
> had crashed.

Thanks, should be fixed now.

Message #34 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Wed, 27 Jul 2022 11:51:12 +0200

Po Lu <luangruo <at> yahoo.com> writes:

>> We need to switch back to the original buffer before that Ffuncall, but
>> we don't know what the original function was -- it's just stored in a
>> local variable in prin1(-to-string).
>
> Isn't that problem already present?  IOW, that function is still called
> in the internal buffer under the current code.

I'm not sure what you mean?  That's the problem I'm pointing out, and
asking for suggestions in how to fix.

Message #37 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Po Lu <luangruo <at> yahoo.com>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Wed, 27 Jul 2022 11:58:12 +0200

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Thanks, should be fixed now.

The other bits in PRINTFINISH aren't done, though, are they?  For
instance, the

   if (free_print_buffer)						\
     {									\
       xfree (print_buffer);						\
       print_buffer = 0;						\
     }									\

bits might lead to a memory leak.

Message #40 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Wed, 27 Jul 2022 19:57:59 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Thanks, should be fixed now.
>
> The other bits in PRINTFINISH aren't done, though, are they?  For
> instance, the
>
>    if (free_print_buffer)						\
>      {									\
>        xfree (print_buffer);						\
>        print_buffer = 0;						\
>      }									\
>
> bits might lead to a memory leak.

Right, thanks.  I fixed that as well.

Message #43 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Thu, 28 Jul 2022 03:47:38 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> Right, thanks.  I fixed that as well.

Thanks for the fix.  My use case seems to behave sane now.

Michael.

Message #48 received at 56773-done <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56773-done <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Thu, 28 Jul 2022 10:53:57 +0800

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Po Lu <luangruo <at> yahoo.com> writes:
>
>> Right, thanks.  I fixed that as well.
>
> Thanks for the fix.  My use case seems to behave sane now.
>
> Michael.

Closing, thanks for testing.

Message #51 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Thu, 28 Jul 2022 11:48:58 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> Right, thanks.  I fixed that as well.

As I said earlier, I suspect that all of PRINTFINISH should go into the
unwind_protect form.  For instance, in the MARKERP situation, it seems
to want to adjust markers etc.  I have not analysed in detail, but those
code bits are presumably there for a reason, and may have to be run if
prin1 has done sometime (even if there's then been a non-local exit).

Message #54 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Thu, 28 Jul 2022 18:44:49 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> As I said earlier, I suspect that all of PRINTFINISH should go into the
> unwind_protect form.  For instance, in the MARKERP situation, it seems
> to want to adjust markers etc.  I have not analysed in detail, but those
> code bits are presumably there for a reason, and may have to be run if
> prin1 has done sometime (even if there's then been a non-local exit).

I don't think that's very intuitive, since signalling means "get me out
of here now".

Message #57 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Thu, 28 Jul 2022 12:46:30 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> I don't think that's very intuitive, since signalling means "get me out
> of here now".

But we shouldn't leave things in an inconsistent state, and I suspect
that we currently do.

By the way, did you look at the test failure your change led to?

Message #60 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Thu, 28 Jul 2022 19:06:21 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> But we shouldn't leave things in an inconsistent state, and I suspect
> that we currently do.

I don't see any inconsistency, just the position of a marker being
changed.

> By the way, did you look at the test failure your change led to?

I didn't see one, but the spam filter is rather agressive these days, so
it would be nice for you to send it again in reply to this message.

Thanks.

Message #63 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Thu, 28 Jul 2022 13:09:08 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> I didn't see one, but the spam filter is rather agressive these days, so
> it would be nice for you to send it again in reply to this message.

Test terpri backtrace:
  signal(ert-test-failed (((should (string= (with-current-buffer (mark
  ert-fail(((should (string= (with-current-buffer (marker-buffer stand
  (if (unwind-protect (setq value-197 (apply fn-195 args-196)) (setq f
  (let (form-description-199) (if (unwind-protect (setq value-197 (app
  (let ((value-197 'ert-form-evaluation-aborted-198)) (let (form-descr
  (let* ((fn-195 #'string=) (args-196 (condition-case err (let ((signa
  (let ((standard-output (save-current-buffer (set-buffer (get-buffer-
  (closure (t) nil (let* ((fn-135 #'string=) (args-136 (condition-case
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name terpri :documentation nil :body (clos
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "-l" "src/print-tests.el" "--ev
  command-line()
  normal-top-level()
Test terpri condition:
    (ert-test-failed
     ((should
       (string=
	(with-current-buffer ... ...)
	"--------\n"))
      :form
      (string= "" "--------\n")
      :value nil :explanation
      (arrays-of-different-length 0 9 "" "--------\n" first-mismatch-at 0)))
   FAILED  41/45  terpri (0.000117 sec) at src/print-tests.el:110
   passed  42/45  test-dots (0.000062 sec)
   passed  43/45  test-prin1-overrides (0.000066 sec)
   passed  44/45  test-prin1-to-string-overrides (0.000049 sec)
   passed  45/45  test-unreadable (0.000029 sec)

Ran 45 tests, 44 results as expected, 1 unexpected (2022-07-28 13:08:34+0200, 0.132581 sec)
3 expected failures

1 unexpected results:
   FAILED  terpri

Message #66 received at 56773 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 56773 <at> debbugs.gnu.org
Subject: Re: bug#56773: 29.0.50; (readablep UNREADABLE) causes strange things
Date: Thu, 28 Jul 2022 19:21:24 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Po Lu <luangruo <at> yahoo.com> writes:
>
>> I didn't see one, but the spam filter is rather agressive these days, so
>> it would be nice for you to send it again in reply to this message.
>
> Test terpri backtrace:
>   signal(ert-test-failed (((should (string= (with-current-buffer (mark
>   ert-fail(((should (string= (with-current-buffer (marker-buffer stand
>   (if (unwind-protect (setq value-197 (apply fn-195 args-196)) (setq f
>   (let (form-description-199) (if (unwind-protect (setq value-197 (app
>   (let ((value-197 'ert-form-evaluation-aborted-198)) (let (form-descr
>   (let* ((fn-195 #'string=) (args-196 (condition-case err (let ((signa
>   (let ((standard-output (save-current-buffer (set-buffer (get-buffer-
>   (closure (t) nil (let* ((fn-135 #'string=) (args-136 (condition-case
>   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
>   ert-run-test(#s(ert-test :name terpri :documentation nil :body (clos
>   ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
>   ert-run-tests((not (or (tag :expensive-test) (tag :unstable))) #f(co
>   ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable)))
>   ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
>   eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
>   command-line-1(("-L" ":." "-l" "ert" "-l" "src/print-tests.el" "--ev
>   command-line()
>   normal-top-level()
> Test terpri condition:
>     (ert-test-failed
>      ((should
>        (string=
> 	(with-current-buffer ... ...)
> 	"--------\n"))
>       :form
>       (string= "" "--------\n")
>       :value nil :explanation
>       (arrays-of-different-length 0 9 "" "--------\n" first-mismatch-at 0)))
>    FAILED  41/45  terpri (0.000117 sec) at src/print-tests.el:110
>    passed  42/45  test-dots (0.000062 sec)
>    passed  43/45  test-prin1-overrides (0.000066 sec)
>    passed  44/45  test-prin1-to-string-overrides (0.000049 sec)
>    passed  45/45  test-unreadable (0.000029 sec)
>
> Ran 45 tests, 44 results as expected, 1 unexpected (2022-07-28 13:08:34+0200, 0.132581 sec)
> 3 expected failures
>
> 1 unexpected results:
>    FAILED  terpri

Thanks, I see the problem now and will push a fix.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.