apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: cvs commit: apr/test testdso.c
Date Sun, 29 Dec 2002 17:21:43 GMT
At 12:21 AM 12/29/2002, rbb@apache.org wrote:

>On 29 Dec 2002 wrowe@apache.org wrote:
>> wrowe       2002/12/28 21:44:02
>>     First; once any apr object is closed, the results are undefined.
>>   Index: testdso.c
>>   --- testdso.c       19 Dec 2002 16:15:29 -0000      1.30
>>   +++ testdso.c       29 Dec 2002 05:44:01 -0000      1.31
>>   ...
>>   @@ -155,17 +155,11 @@
>>        status = apr_dso_unload(h);
>>        CuAssert(tc, apr_dso_error(h, errstr, 256), APR_SUCCESS == status);
>>   -
>>   -    status = apr_dso_sym(&func1, h, "print_hello");
>>   -    CuAssertIntEquals(tc, APR_EINIT, status);
>>    }
>I seriously disagree with this change.  

>If the dso is unloaded, you
>shouldn't be able to find a symbol in it anymore.  

I agree with you.  However, h is now undefined.  This means that we
will generally react by segfaulting or throwing any indeterminate error.
EINIT is a Unixism.

>One of the points of
>APR is that it removes this kind of platform difference.  Right now,
>somebody can program on Windows, and use the wrong pool to load a library.
>Then, after the pool is cleared still be able to dso_sym that library.

Why do you suppose they can do that?  Win32 returns an error, just
not that specific error.  The test failed because the result was not
EINIT.  Once a file/dso/shm/pipe/socket etc is closed/unloaded, that's
it, game over.  How a platform expresses the error is undefined.

>However, if that program is then brought to another platform, it will no
>longer work.

It doesn't work today once the symbol is unloaded.

>I am currently -0.9 for this change.  Is there a reason we can't solve
>this problem so that incorrect pool scope can be easily found on all

That's a bogus arguement.  If h is within a more-limited pool scope 
than the programmer intended, then the next apr_dso_sym() *will* 
segfault, and not return some gracious EINIT.

Win32 invalidates the object handle within the apr_dso_t (as it does
for many other objects.)  Double-closing is protected by the pre-test
for an invalid handle.

If you want to define the behavior of all functions following closure or
unloading, then you must go through all platforms and introduce tests
for a valid handle on all operations.  I really think that is overkill and
undermines the original design constraints.

However, as I suggested when we first argued the issue of argument
checking, it isn't unreasonable to have small sections such as...

APR_DECLARE(apr_status_t) apr_foo_fn(apr_foo_t *t)
    if (!t) 
        return APR_EINVAL;
    if (!t->ptrmbr)
        return APR_EINIT;

[code body]


It's all in the distinction between *defined* behavior, which can be tested,
and *undefined* behavior which is untestable.  {Unless we can test sevg
as a success case, perhaps using STL exceptions.}


View raw message