bug#50268: 28.0.50; Assertion warning during native compilation

[Andrea Corallo]

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Michael Welsh Duggan <mwd@md5i.com> writes:
>
>> I was able to determine that there was a bug in the pacproxy.el code
>> that I included in the bug report.  Fixing that bug caused native
>> compilation to work.  The assertion and backtrace were not particularly
>> useful in determining the bug in the code, though.  The bug was in the
>> `pacproxy--retrieve-wpad' function when I let-bound the following
>> illegal lambda:
>>
>>   (lambda (&rest) "DIRECT")
>>
>> The fix was to change this to:
>>
>>   (lambda (&rest _) "DIRECT")
>>
>> Is there another part of the compiler that could have caught this and
>> returned a useful diagnostic?
>
> Hi Michael & all,
>
> I had a quick look and these are my findings:
>
> (byte-compile '(lambda (&rest _) "DIRECT"))
> =>
> #[128 "\300\207" ["DIRECT"] 2 "DIRECT
>
> (fn &rest _)"]
>
> Here we have as encoded signature 128 (one rest arg) and the frame size
> is 2 (one for the rest arg and one for the immediate). Fine...
>
> (byte-compile '(lambda () "DIRECT"))
> =>
> #[0 "\300\207" ["DIRECT"] 1 "DIRECT"] 
>
> Here we have as encoded signature 0 (no args) and the frame size is 1
> (will be used by the immediate).  Fine as well.
>
> (byte-compile '(lambda (&rest) "DIRECT"))
> =>
> #[128 "\300\207" ["DIRECT"] 1 "DIRECT
>
> (fn &rest)"]
>
> This is the problematic case that was signaled as reproducer.  Here we
> have as encoded signature 128 (one rest arg) but the frame size (1) is
> not accounting for this.
>
> I think this output is a incoherent and I guess the byte compiler should
> probably just raise an error and refuse to compile if the lambda list is
> invalid.  Am I wrong?

I can't verify in this moment but I guess is very possible we even
overflow in the byte interpreter when executing the mentioned bytecode.

  Andrea