GNU bug report logs - #71555
29.3.50; Native-compilation sets some variable to nil unexpectedly.

Previous Next

Full log

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

From: Andrea Corallo <acorallo <at> gnu.org>
To: Sévère Durand <mmemmew <at> gmail.com>
Cc: 71555 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#71555: 29.3.50; Native-compilation sets some variable to
 nil unexpectedly.
Date: Mon, 17 Jun 2024 03:25:09 -0400

Sévère Durand <mmemmew <at> gmail.com> writes:

> Hello:
>
> I recently found that sometimes an argument of a function is
> unexpectedly set to nil when the function is natively compiled.
>
> A recipe to reproduce the behaviour is as follows.
>
> ```elisp
> (defun test (&optional start)
>   "Test the values of START."
>   (message "start is %S" start)
>   (cond
>    ((not (integer-or-marker-p start))
>     (message "entered first cond variant")
>     (setq start nil))
>    ((and
>      (markerp start)
>      (not (equal (marker-buffer start) (current-buffer))))
>     (message "entered second cond variant")
>     (setq start nil)))
>   (message "start is %S" start))
> (native-compile 'test)
> (test 12)
> ```
>
> When I evaluate the above forms in sequence, I got the following two
> messages:
>
> start is 12
> start is nil
>
> As can be seen from the above, no `cond` variants are triggered, so the
> variable START should have the value 12, while it becomes nil at the
> end.
>
> Sorry if this example is not minimal: I found this behaviour in my
> package, so copied the relevant parts here.  I am not sure what a 
> minimal example would be.
>
> Hope this report is helpful.

Hi Sévère,

I can't reproduce on master so the bug there is fixed.

AFAIK we don't plan to release a new 29 so I'm not sure it's worth the
effort of investigating and producing a backport for this bug.

Eli WDYT?

Thanks

  Andrea

Previous Next

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