[Top][All Lists]

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

Re: [External] : Re: Question about native compilation (bug?)

From: Andrea Corallo
Subject: Re: [External] : Re: Question about native compilation (bug?)
Date: Thu, 27 Jul 2023 14:38:07 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Drew Adams <drew.adams@oracle.com> writes:

>> > What about my other questions, e.g. wrt fixing this?
>> I haven't done any recent analysis, from what I remember it is not
>> easily fixable.
>> That said I think is not worth of, redefining primitives is already
>> discouraged by the manual and dangerous (more on that later), doing it
>> with a different signature it's just kamikaze behavior.
>> Note also that redefining primitives in Emacs is not only disincouraged,
>> but is really not guaranteed to work properly.  The redefinition will
>> not take effect executing bytecode if the primitive has a dedicated
>> byteopcode and it will *not* take effect either for any call to the
>> primiteve done form C itself.
> I don't claim to understand all of that, e.g.
> primitives that do or don't have dedicated
> byteopcodes etc.
> The fact is that it does work for `read-buffer',
> except when native compilation is turned on.
> Except, of course, for calls from C itself -
> that's understandable (nothing new about that).
> The point is to have compatibility with what
> happens with Lisp source code.

As I said that is already broken in multiple ways.  Try redefining + and
you'll discover that: it works in interpreted code, it does not when
executing bytecode, it does again from native code, it does not from C
calls.  Not only, the byte compiler assumes primitives are what they are
and they are not redefined, so byte compiling code you might get
spurious warnings or a miss-compiled output.

You just touched the tip of an iceberg of something we don't support and
we ask the user not to do.


reply via email to

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