I spent a little time on Monday and Tuesday looking at this in the debugger and it looks like the behavior I am seeing is probably related to compiler optimizations. My testing showed that the fixes you committed (64 bit atoi and conversion to use seconds) seem to have fixed the random behavior I was seeing.
Thanks. Brian Pane wrote: > On Sat, 2002-10-12 at 20:26, Paul J. Reder wrote: > >>Okay, this takes care of item 4 from the list below. Thanks Brian, saves >>me from having to do the commit. :) >> >>What about the other 3? Should they be fixed by the change from >>apr_time_t to apr_int64_t? Apr_time_t is really apr_int64_t under >>the covers and I was seeing only the lower 32 bits being set when >>the variables were assigned "0" and "-1". The value was correctly >>set when it was assigned APR_DATE_BAD (which has an embedded cast) >>so it seems that 1-3 still need to be done. >> > > If I remember correctly, the ANSI arithmetic conversion rules > should cause the 0 or -1 to be sign-extended to long long (or > whatever other integral type apr_int64_t is typedef'ed to). > > Brian > > > > -- Paul J. Reder ----------------------------------------------------------- "The strength of the Constitution lies entirely in the determination of each citizen to defend it. Only if every single citizen feels duty bound to do his share in this defense are the constitutional rights secure." -- Albert Einstein
