bug#37415: Asserting failure setting frame parameters to non-fixnum values in early-init.el

[Eli Zaretskii]

> Cc: lekktu@gmail.com, 37415@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 21 Sep 2019 10:51:49 +0200
> 
> I get a similar backtrace when I try the more reasonable
> 
> (setq default-frame-alist '((left . (- 100))))
> 
> in my early-init.el (more reasonable because, after all,
> 
> (setq default-frame-alist '((left . (+ 0))))
> 
> is equivalent to
> 
> (setq default-frame-alist '((left . 0)))
> 
> which _can_ be handled from within early-init.el).  Do we agree so
> far?  If so, then obviously
> 
>    if (EQ (left, Qunbound))
>      coords[0] = CW_USEDEFAULT;
>    else
>      coords[0] = XFIXNUM (left);
> 
> will choke when 'left' is something like '(+ 0)' or '(- 100)' since
> neither of these pass the
> 
> eassert (FIXNUMP (a))
> 
> check we have in XFIXNUM.  Still agreed?  Then doing something like
> 
>    if (FIXNUMP (left))
>      coords[0] = XFIXNUM (left);
>    else
>      coords[0] = CW_USEDEFAULT;
> 
> should fix the assertion failure if my poor understanding of C doesn't
> let me down completely (the 'top' parameter needing a similar fix).
> Does that reasoning still make sense to you?
> 
> And finally, with the sole evidence of my poor eyesight,
> 
> (setq default-frame-alist '((left . (- 100))))
> 
> seems to work here too, despite of the fact that for the first frame
> the defaults are used.  Maybe you can try to verify (I attach the
> patch for easier use this time).

Thanks, but I probably should have explain the nature of my confusion
better (and would have done that, should I know you will act upon it
so seriously).  Sorry about that.

Here's what confused me in this problem:

  . the FIXNUMP assertion is probably there for a reason; what is that
    reason?
  . how come we don't hit this assertion when the same expression is
    in the init file, only in the early-init file?
  . why doesn't the X build hit the same assertion in the same
    scenario?

I'm probably missing something because I don't find answers to these
questions anywhere in what you wrote.  I do understand the "mechanics"
of the patch, I just cannot convince myself it's the right fix,
without being able to answer these questions, and then assess the fix
with that knowledge in hand.  Which shouldn't prevent you from
installing it, of course: I don't have to understand everything in
what's going on in Emacs development.

> So do you still think that we should signal an error?

A red herring: I only proposed to signal an error if we cannot find a
better solution for this use case.