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

[Drew Adams]

> > 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.

If this can't/won't be fixed, so be it.  But it
makes Elisp code with native compilation behave
differently from Elisp code that's either source
or byte-compiled.

How much do we care about native compilation
respecting the same behavior as source code?

If this won't be fixed, or until it is, shouldn't
such incompatibility be called out in the doc?
___

Even aside from imagining redefinitions, does
it make sense for a source-code function call
that passes N args to be changed to a call that
passes N args plus M nil args?  That's really
what this is about, it seems to me: reproducing
the actual call, as is, instead of adding
explicit nil optional args.  We don't do that
with byte compilation, right?  Why should we
need to do it with native compilation?