[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31688: 26.1.50; Byte compiler confuses two string variables

From: Phil Sainty
Subject: bug#31688: 26.1.50; Byte compiler confuses two string variables
Date: Mon, 04 Jun 2018 22:02:27 +1200
User-agent: Orcon Webmail

On 2018-06-04 01:05, Andreas Schwab wrote:
On Jun 04 2018, Phil Sainty <address@hidden> wrote:
I generally dislike it when byte-compiled and interpreted code
give different results.

This really has nothing to do with byte-compilation.  Whether
literals are shared or not should not be relied upon.  You always
have to be careful when modifying values in-place.

I don't disagree that one ought to take care when modifying values
in-place, but my general concern is purely that the byte-compiler is
producing code which does not behave the same as the uncompiled code.
(i.e. I think my issue is specifically to do with byte-compilation,
and I would consider such discrepancies to be a problem irrespective
of the sort of code which was affected.)

Surely consistent behaviour between compiled and uncompiled code is
not only desirable, but a primary goal?

I realise (albeit vaguely) that the byte code and its interpreter are
rather different to the uncompiled versions, so I suppose this may not
be the only situation where a discrepancy results; but I think that
known cases ought be identified and documented (and I think that
eliminating such differences may be a valuable improvement).

The "(elisp)Byte Compilation" info node could certainly do with a
child node detailing the ways in which byte-compiled code behaves
differently from uncompiled code, so that elisp authors can gain an
understanding of all these nuances from a single section of the

Whether literals are shared or not should not be relied upon.


I mean, in this case we already know the answer, but why shouldn't the
behaviour be consistent and dependable between the two variants?

Again, it bothers me to think that someone could observe a bug when
running byte-compiled code, and try to debug it but, through the
process of instrumenting functions for debugging, unwittingly change
the behaviour of the code such that the bug no longer occurs.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]