[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39944: 27.0.90; JIT Stealth timer errors
From: |
Eli Zaretskii |
Subject: |
bug#39944: 27.0.90; JIT Stealth timer errors |
Date: |
Sat, 07 Mar 2020 20:29:47 +0200 |
> Cc: 39944@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 7 Mar 2020 10:02:28 -0800
>
> > (the comments in that part of the code can really use some
> > enhancement; they currently seem to target only experts in both time
> > handling and GMP: many macros whose names don't explain what they do,
> > and plethora of calls to libgmp functions that have no comments
> > whatsoever).
>
> Although comments in that area no doubt could use improvement, I'd rather not
> see comments like this:
>
> /* Add TM_YEAR_BASE to mpz[0]. */
> mpz_add_ui (mpz[0], mpz[0], TM_YEAR_BASE);
There are quite a few of similar comments there, and they actually
help, because they save us from consulting the GMP manual on every
step.
But I really meant that stuff like this lacks a comment:
hz = make_integer_mpz ();
mpz_swap (mpz[0], *iticks);
ticks = make_integer_mpz ();
And also functions like timespec_ticks, lisp_time_hz_ticks, and
lisp_time_seconds, which don't have a single comment describing how
they do their thing. Following that code with the purpose of tracking
some specific result is not for the faint at heart. I think adding a
comment here and there might make that easier.
> > + (when (numberp time)
> > + (setq time (timer-relative-time nil time))
> > + (or (consp time)
> > + (setq time (time-convert time 'list))))
>
> This would catch some problems but not all, as the real bug here is in the
> code
> (or (consp time) (error "Invalid time format")) which occurs a few lines
> later.
> As near as I can tell this later code is both wrong and unnecessary. It's
> wrong
> because it's no longer true that only conses are time values. It's
> unnecessary
> because the immediately following (timer-set-function timer function args)
> call
> checks the validity of TIME. On the off chance that a validity check is still
> helpful (because we don't want to create garbage?) I installed the attached
> patch.
Thanks.
> But it might be better in master to remove the "Invalid time format"
> check entirely.
I'm fine with removing that test, if we are sure that invoking
run-at-time with something utterly un-timely, like a symbol or a a
string that cannot be a valid time description, will trigger an error
(presumably from timer-set-time).