Question about native compilation (bug?)

[Drew Adams <drew.adams@oracle.com>]

I don't have native compilation for my laptop, but I received a bug report from a user of one of my libraries, and I get the feeling that native compilation (which this user has) is interfering and perhaps bugged.

1. My code, when loaded, saves the original definitions of some functions, such as `read-buffer', by creating a `defalias' for each of them, such as this one:

(defalias 'ORIG-read-buffer
          (symbol-function 'read-buffer)

2. I define a global minor mode that, when turned on, redefines those saved functions, such as `read-buffer', using `fset', to using definitions appropriate to the minor mode.  

3. When the minor mode is turned off I reset those function definitions to the saved (`defalias'ed) versions, using `fset'.

(I do this dance because I want the library to work properly also with older Emacs versions.  No comments, please, about its fragility or other weaknesses.)
___

This is the problem, reported in Emacs 28.2 with native compilation:

Emacs 28 added an additional optional arg to function `read-buffer' (which is defined in C).  My substitute version of `read-buffer', which is used when my minor mode is turned on, has only 1 required arg and 2 optional, not 1 required and 3 optional.

Obviously, for any code that will try to pass 4 args, I need to update my code to accommodate the 4th arg.  I haven't done that yet.

But my question is about code that ostensibly passes 3 or fewer args.  An error is nevertheless raised, saying that 4 args were passed and only 3 were allowed.  The standard code, whose vanilla source definition (in `window.el') passes only 3 args, in actuality, at runtime, passes 4 args, the 4th one being explicitly nil.

Recipe: the minor mode is turned on, and `C-x 5 b' is tried.  An error is raised:

Debugger entered--Lisp error: (wrong-number-of-arguments #<subr my-read-buffer> 4)
  read-buffer("Switch to buffer in other frame: " #<buffer foo> confirm-after-completion nil)
  read-buffer-to-switch("Switch to buffer in other frame: ")
  byte-code("\300\301!C\207" [read-buffer-to-switch "Switch to buffer in other frame: "] 2)
  call-interactively(switch-to-buffer-other-frame nil nil)
  command-execute(switch-to-buffer-other-frame)

I wouldn't have a clue to what is going on here from that backtrace, since function `my-read-buffer' accepts 3 args and the source code for `read-buffer-to-switch' passes 3 args.

I got a glue (I think), from this: For the reporting user `C-h k C-x 5 b' says this:

C-x 5 b runs the command switch-to-buffer-other-frame (found in global-map), which is an interactive native-compiled Lisp function in '/var/lib/snapd/snap/emacs/2031/usr/share/emacs/28.2/lisp/window.el'.

It's that "native-compiled" that makes me wonder.  If the user loads the Lisp source file, `window.el', there's no problem.  But it looks kinda like native compilation has "baked-in" the call to `read-buffer', passing an explicit 4th arg, nil, instead of passing only the 3 args that the source code says to pass.

Passing 4 args, the last of which is nil, isn't the same thing as passing 3 args, but it looks like native compilation takes a shortcut, assuming that it's the same thing.

Is this a native-compilation bug?  Is it some other Emacs bug?  Or is this just the way things are going to be from now on - "situation normale, rien à signaler"?

Let me know, if my guesses are near the target, or if I'm missing something.