httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: cvs commit: httpd-apreq-2/env/t/cgi-bin .cvsignore
Date Fri, 24 Oct 2003 18:07:18 GMT
Stas Bekman <stas@stason.org> writes:

> Joe Schaefer wrote:
> 
> > ... I had some problems running the
> > tests with apr's current cvs- apr_env_get's behavior may have changed
> > slightly, and I was getting segfaults on cgi tests 1-9. Initializing
> > value = NULL took care of those.
> 
> What was the exact problem? 

Segfaults on RH8, because apreq_env_header_in returns an uninitialized
value whenever apr_env_get failed.  On a lucky platform, that
unitialized value was zero, which is fine.  On my (unlucky) platform, 
the returned value was 1.

> apr_env_get hasn't changed and its implementation on unix (assuming
> that's where you had this problem) is as simple as:
> 
> APR_DECLARE(apr_status_t) apr_env_get(char **value,
>                                        const char *envvar,
>                                        apr_pool_t *pool)
> {
> #ifdef HAVE_GETENV
> 
>      char *val = getenv(envvar);
>      if (!val)
>          return APR_ENOENT;
>      *value = val;
>      return APR_SUCCESS;
> 
> #else
>      return APR_ENOTIMPL;
> #endif
> }
> 
> As long as you check for APR_SUCCESS the value should be OK to you
> without initializing it. I think the workaround of initting it to NULL
> hides the real problem. 

It's just fine so long as apr_env_get only mangles its first argument
on APR_SUCCESS.  apreq_env_header_in() must return NULL when apr_env_get
fails; initializing value = NULL ensures that will happen.

> I did suggested to use a macro APREQ_ENV_STATUS to make the testing

I'm not a fan of that particular macro.

-- 
Joe Schaefer


Mime
View raw message