Re: mktime() problem when building print/a2ps

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Fri, 14 Oct 2022 09:13:19 +0200
    From:        Thomas Klausner <wiz%NetBSD.org@localhost>
    Message-ID:  <Y0kMD/UVLhEcBCnA%yt.nih.at@localhost>


  | and this takes much longer! It's now been running ten minutes.

That isn't supposed to happen.   The first (executable) line of main
is
	alarm(60);
which should make the program exit after 60 seconds, whatever else
goes wrong.   That's what happens for me when I run configure.
Surprisingly (and this must indicate a bug in the configure script
I think, though I did not go looking for what) the program in the
test does exit (for me) with SIGALRM after a minute, but the script
still goes on to conclude that the system mktime() is fine (does not
substitute the replacement version).

The next line after that one is:

	for (time_t_max = 1; 0 < time_t_max; time_t_max *= 2)
		continue;

(different indentation than in this message, but otherwise that).
I can see what that is attempting to do, but that code makes me
cringe.   It makes current gcc cringe too, the code generated for
that loop, according to gdb, is ...

=> 0x0000000000400b88 <+14>:    jmp    0x400b88 <main+14>

in fact, let me show the entire main() as reverse assembled by gdb:

Dump of assembler code for function main:
   0x0000000000400b7a <+0>:     push   %rbp
   0x0000000000400b7b <+1>:     mov    %rsp,%rbp
   0x0000000000400b7e <+4>:     mov    $0x3c,%edi
   0x0000000000400b83 <+9>:     call   0x400620 <alarm@plt>
=> 0x0000000000400b88 <+14>:    jmp    0x400b88 <main+14>
End of assembler dump.

There is the function entry, call to alarm(0x3c)  (0x3c == 60)
and an infinite loop doing nothing.

gcc (with -O2 probably, though some of the other options may also be
relevant) has compiled that loop, which uses undefined behaviour
(assuming that big number * 2 becomes negative number) into the
result, a loop which can never end (starting with a positive number
and multiplying by another positive number can never, mathematically,
produce a negative number).  So that's what the code does, without
bothering to waste any time multiplying (or even shifting).

This has nothing whatever to do with mktime() - the code never runs
mktime(), it is simply a broken configure script (and far more broken
than just that one line).

It all works when not compiled with optimisation turned on.

kre