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 04:45:16 GMT
Justin Erenkrantz wrote:

> On Tue, Jan 29, 2002 at 01:44:32AM +0800, Stas Bekman wrote:
>>apr_date's apr_date_parse_rfc function modifies the date string in the 
>>caller's namespace and corrupts it. I didn't test all cases but only the 
>>accepted formats, for the .h docs:
> That's why you are also passing in a char* not a const char*.  I
> didn't want to rewrite all of the date code to handle the oddball
> dates - I figured it'd be easier to note that the char* could be
> changed rather than incur a copy.

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?

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.

> Feel free to submit a patch that makes it const char* (probably only
> need to copy the date if it's an oddball).  The only place that is 
> using this code is mod_mbox, but we could do some cleanups so that
> others can use it with a const char* expectation.

yeah, I started to work on it, but then something weird happens when I 
try to debug it.

>>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.

>>I've tried walking through the code with gdb, but it looks like code 
>>gets optimized in a weird way, so I see completely bogus values of date 
>>while stepping through it.
> Make sure you are using -g - this code can be extremely optimized
> by the compiler, so stepping through with gcc's optimiziations on
> can cause headaches.

I build with --enable-maintainer-mode, which enables  '-g -O2 ...'. 
Could it be a problem of -O2?

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