You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2005/10/29 05:31:07 UTC
Re: svn commit: r17078 - in trunk/subversion: mod_authz_svn
On Fri, 2005-10-28 at 13:15 -0500, kfogel@tigris.org wrote:
> Author: kfogel
> Date: Fri Oct 28 13:15:50 2005
> New Revision: 17078
>
> Modified:
> trunk/subversion/libsvn_subr/error.c
> trunk/subversion/mod_authz_svn/mod_authz_svn.c
>
> Log:
> Follow up to r17077: Use sizeof() instead of a hardcoded buffer length.
Why are we using fixed-sized buffers at all?
(I realize this seems to date to a pre-existing svn_strerror(), but it
seems like a botch which should be corrected, not propagated to a new
interface.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r17078 - in trunk/subversion: mod_authz_svn
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-11-03 at 08:51 -0600, kfogel@collab.net wrote:
> I think we're doing it to avoid allocating memory, the assumption
> being that running out of memory might have been the ultimate cause of
> whatever error we're handling.
But we don't have any out-of-memory handling in Subversion. We crash if
we can't allocate memory.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r17078 - in trunk/subversion: mod_authz_svn
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> > Log:
> > Follow up to r17077: Use sizeof() instead of a hardcoded buffer length.
>
> Why are we using fixed-sized buffers at all?
>
> (I realize this seems to date to a pre-existing svn_strerror(), but it
> seems like a botch which should be corrected, not propagated to a new
> interface.)
I think we're doing it to avoid allocating memory, the assumption
being that running out of memory might have been the ultimate cause of
whatever error we're handling. At any rate, this was why I chose to
propagate the API rather than "fix" it. See the note in the docstring
of svn_err_best_message().
(I'm not wedded to this decision, just explaining it...)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org