apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: apr_date's functions corrupt the caller's data.
Date Tue, 29 Jan 2002 17:23:01 GMT
Justin Erenkrantz wrote:

> On Tue, Jan 29, 2002 at 12:45:16PM +0800, Stas Bekman wrote:
>>yes, but the documentation doesn't note this. Does this mean that any 
>>API that doesn't specify const, is free to change the data without 
>>saying so?
> In theory, yes.  But, it *should* be noted in the documentation as
> well.  Please feel free to submit a patch to fix that.  However,
> the real thing to do is to make it so that it doesn't need to
> modify the char* or make it copy when it sees the odd formats.

ok, I'll try tomorrow.

>>Also I think the docs are wrong. the functions return the number of 
>>seconds and not micro-seconds:
>> * @return the apr_time_t number of microseconds since 1 Jan 1970 GMT, or
>> *         0 if this would be out of range or if the date is invalid.
> It returns usecs not seconds.  None of the apr functions use
> seconds.  I'm not sure how you see that it returns seconds.

scratch that, it works correctly. I was testing with the perl interface 
and it automatically converts these into seconds on type conversion. 
Sorry for a false alarm.

>>>>This code also could corrupt the data:
>>>>      if ((date = strchr(date, ' ')) == NULL)   /* Find space after 
>>>>weekday */
>>>>          return APR_DATE_BAD;
>>>>this one happens in _http version as well.
>>>Do you have any thoughts on how to resolve this?  We are assuming
>>>that we're working with a valid string.  It'll stop at a term
>>>NULL.  If you pass in a non-NULL terminated string, too bad, IMHO.
>>I dunno, I think that the moment you want to modify a string you have to 
>>copy it.
> This has nothing to do with modifying the string.  We want to
> change the local pointer to point *after* the space.  This eases the
> later compuations.  I think the strchr is safe in this context.

true again, the optimized code got me confused.

>>I build with --enable-maintainer-mode, which enables  '-g -O2 ...'. 
>>Could it be a problem of -O2?
> Yes.  I compile with "-g -Wall" - O2 turns on optimizations and
> makes stuff like this awful to debug.  Compiling without that O2
> should make the gdb debugging easier.  -- justin

Will try to fix things and send the patch soon.

Thanks Justin.

Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker
http://stason.org/      mod_perl Guide   http://perl.apache.org/guide
mailto:stas@stason.org  http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

View raw message