Re: Certain numbers of special forms cause changing behaviour on function calls in --batch

[Eli Zaretskii <eliz@gnu.org>]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 10 Jul 2016 12:23:17 -0400
> Cc: Yasushi SHOJI <yasushi.shoji@gmail.com>, Michael Heerdegen <michael_heerdegen@web.de>, me@wilfred.me.uk, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Sun, Jul 10, 2016 at 10:53 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Noam Postavsky <npostavs@users.sourceforge.net>
> >> Date: Sun, 10 Jul 2016 07:33:47 -0400
> >> Cc: Eli Zaretskii <eliz@gnu.org>, Michael Heerdegen <michael_heerdegen@web.de>, me@wilfred.me.uk,
> >>       Emacs developers <emacs-devel@gnu.org>
> >>
> >> I have gcc 5.3.0 here, and I get 10 (correct) when I compile Emacs
> >> 24.5 configured with --enable-checking, but 20 (incorrect) without
> >> that flag.
> >
> > I've just built 24.5 with GCC 5.3.0 and without --enable-checking, and
> > I still don't see the problem in the resulting binary.
> 
> Hmm, that's annoying.

This whole issue is annoying.

> >> valgrind emacs-24.5/src/temacs -Q --batch -l nasty-move-end-of-line-batch.el
> >> [...]
> >> ==6167== Conditional jump or move depends on uninitialised value(s)
> >> ==6167==    at 0x55E74E: CHECK_NUMBER_OR_FLOAT (lisp.h:2627)
> >> ==6167==    by 0x5EC762: Fzerop (data.c:2387)
> >
> > I don't understand these errors.  Please show the macro-expanded
> > source of Fzerop with that compiler and configuration options.
> 
> I don't think Fzerop is especially relevant, AFAICT, the error just
> means Fzerop received an unitialized value as its first argument.

Sorry, I;m not following: Fzerop is called from Ffuncall, i.e. from
Lisp, so how can the value of Fzerop's argument be uninitialized?
What am I missing?

> Lisp_Object Fzerop (Lisp_Object) ; static struct Lisp_Subr
> # 2383 "data.c" 3 4
> _Alignas
> # 2383 "data.c"
> (8) Szerop = { { PVEC_SUBR << PSEUDOVECTOR_AREA_BITS }, { .a1 = Fzerop
> }, 1, 1, "zerop", 0, 0}; Lisp_Object Fzerop
> 
>   (register Lisp_Object number)
> {
>   CHECK_NUMBER_OR_FLOAT (number); //// <<<<---- this is line 2387
> 
>   if ((((enum Lisp_Type) ((number) & ~(
> # 2389 "data.c" 3 4
>      1
> # 2389 "data.c"
>      ? - (1 << 3) : (0x7fffffffffffffffL >> (3 - 1))))) == Lisp_Float))
>     {
>       if (XFLOAT_DATA (number) == 0.0)
>  return Qt;
>       return Qnil;
>     }
> 
>   if (!((number) >> INTTYPEBITS))
>     return Qt;
>   return Qnil;
> }

That's what I see, thanks.  Very strange, this error from valgrind.
And we are none the wiser.