GNU bug report logs - #67141
30.0.50; Missing element in the backtrace

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Sun, 12 Nov 2023 22:31:01 UTC

Severity: normal

Found in version 30.0.50

Full log


View this message in rfc822 format

From: Andrea Corallo <acorallo <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 67141 <at> debbugs.gnu.org
Subject: bug#67141: 30.0.50; Missing element in the backtrace
Date: Mon, 20 Nov 2023 13:16:39 -0500
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> If you want then I think we should consider this bug not only native
>> comp related, as I explained we have this issue since long time in
>> other circumstances.
>
> I think it's qualitatively different, but yes, this is not the only
> occurrence of the problem.  AFAICT, we have 3 different cases:
>
> A. Native compiled code making a "direct call" to a C primitive.
> B. ELisp primitives with their own bytecode.
> C. C code calling `Ffoo` instead of `Ffuncall (Qfoo, ...)`.
>
> (B) and (C) have been with us for ever.  They also suffer from being
> unaffected by advice.  (A) on the other hand is new, but obeys advice.
>
> I think (C) is qualitatively very different from (A) because
> (C) can be fixed by hand whenever we decide that it's a problem,

Well ATM we can fix A by hand as well with a (declare (speed 0)) in the
calling function.  Admittedly would be nice to have a more narrowed way
to handle this at call site.  I'd e in favor of adding it.  Do you think
this would be sufficient?

  Andrea




This bug report was last modified 1 year and 262 days ago.

Previous Next


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