Re: PATCH: my "SECONDS can be floating point" tweaks

["Bart Schaefer" <schaefer@brasslantern.com>]

On Oct 30,  1:17pm, Wayne Davison wrote:
} Subject: PATCH: my "SECONDS can be floating point" tweaks
}
} I won't commit this until I get some positive feedback about the
} changes.

I think they look good, except (maybe) for one thing:

} First, the intseconds{get,set}fn() functions are implemented by calling
} the float* versions.

Is converting to float and then back to integer (or the other way round
for the setfn) really going to give the same results as a computation
directly on only shtimer.tv_sec?

I wouldn't want to lose or gain an entire second due to rounding errors
when e.g. doing arithmetic in a loop on the integer SECONDS.

(Is "rounding" the right description anyway?  Isn't it _truncated_ to an
integer when the parameter is not set to float?)

I otherwise like the simplicity of this approach.

} The second change may be more controversial.  I introduced two new
} functions that allow us to get and set the "raw" (non-relative to now)
} value of the SECONDS variable (though the value is returned as a
} double).  I then added some code to builtin.c that saves this raw value
} into the cached off u.dval, and changed the new code in params.c that
} was adding local-elapsed time into the parent variable to just reload
} the raw parent value.

I must be sleepy or especially dense at the moment, but I don't follow
what this means from the point of view of the _caller_ of a function in
which SECONDS is local.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net