I'll get it changed :-)
Also, note that last night I added UUID support to APR. If we need
universally unique IDs anywhere in SVN, then apr_get_uuid() will generate
them for you.
[ note: this is much different than simply IDs that need to be internally
unique (to a file or sumtin) ]
SVN doesn't yet need these APR changes, but it will be coming within the new
few days or so (meaning you don't have to grab a new APR just yet).
----- Forwarded message from email@example.com -----
Date: Fri, 6 Oct 2000 15:23:31 -0700 (PDT)
Subject: Re: [firstname.lastname@example.org: request for APR maintainer(s)]
At one time, this was requested, so that we could re-use file pointers I
believe. I don't really remember, but it is a bogus thing. I say remove
the check for NULL everyplace in APR.
We ALWAYS want APR to be the allocator for any incomplete structure.
On Fri, 6 Oct 2000, Greg Stein wrote:
> What is the rationale for a non-NULL pointer to apr_open()? Do we really
> need to be able to supply storage?
> It has bit us in Apache itself, and several times in SVN. I'd like to change
> it, but was unsure whether there was a reason for this behavior.
> [ checking Apache... ]
> I've looked through all the calls that Apache makes to apr_open. The
> *) most initialize the value to NULL first, then call apr_open(). there are
> two or three places in lib/apr/test/*.c that call apr_open() once, then
> do it again later without resetting to NULL. I'm presuming this is a bug
> rather than purposeful behavior. (semantic bug: it works but was probably
> not what the programmer intended)
> *) threadproc/os2/proc.c calls apr_open() without initializing the value to
> NULL first. this isn't a problem because file_io/os2/open.c does NOT
> check for a non-NULL value.
> *) support/htdigest.c has a bug with a call where it doesn't init to NULL
> *) main/http_log.c has a suspicious call
> I would like to change apr_open() to always return new storage. Any
> ----- Forwarded message from Karl Fogel <email@example.com> -----
> Date: Fri, 6 Oct 2000 15:48:10 -0500
> From: Karl Fogel <firstname.lastname@example.org>
> To: email@example.com
> Subject: request for APR maintainer(s)
> Reply-To: firstname.lastname@example.org
> Greg (S), this one's for you, if you agree:
> The requirement to initialize file handles to NULL before passing them
> to apr_open() just bit me again, for probably the twentieth time. I
> spent an hour debugging it, because it manifested as a trashing of
> saved registers, one of which happened to contain the return addr for
> main(). This was a bit frustrating. :-)
> When this topic came up on here once before, you mentioned that a few
> other APR maintainers felt the same way, and that there was a
> possibility the interface to apr_open() would be changed.
> Is this still possible? I have a feeling this is going to keep
> hitting us over and over, and I doubt (?) anyone out there really
> depends on being able to pass non-null handles in.
> Enjoy this excerpt from my GDB session over the phone with JimB
Ryan Bloom email@example.com
406 29th St.
San Francisco, CA 94131
----- End forwarded message -----
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:10 2006