Re: Clarifying structure modification in HACKING was Re: Suppress display of sensitive info by servers (proposal)

[Greg Hudson <gh...@MIT.EDU>]

On Wed, 2005-04-13 at 15:04, Justin Erenkrantz wrote:
> Right now, I think this is implied.  But, that's probably because we've 
> adopted this policy implicitly in APR.  Thoughts?  -- justin

What we'd like, ideally, is a way to publish a structure's contents
without allowing callers to allocate them.  C doesn't provide such a
mechanism, and some programmers will tend to allocate structures even if
a constructor is provided.  (For instance, Greg Stein was fond of
constructing svn_string_t structures in the DAV code even though we have
constructor functions, owing to a misguided attachment to tiny
efficiency gains.)

I think your policy makes sense, but we should document more explicitly
that callers must use our provided constructors for all public
structures.  In most cases, we don't really expect callers to be
motivated to do otherwise (certainly not for svn_error_t), but I don't
think we can treat it as implicit.

Someone suggested doing away with all public structures in 2.0.  I think
that would be kind of inconvenient; str->len would become the less
wieldly svn_string_length(str), etc.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Clarifying structure modification in HACKING was Re: Suppress display of sensitive info by servers (proposal)

[Garrett Rooney <ro...@electricjellyfish.net>]

Greg Hudson wrote:

> I think your policy makes sense, but we should document more explicitly
> that callers must use our provided constructors for all public
> structures.  In most cases, we don't really expect callers to be
> motivated to do otherwise (certainly not for svn_error_t), but I don't
> think we can treat it as implicit.

If we can rely on anything it's that users will do silly things, and no 
matter how little sense it makes to allocate on the stack and manually 
initialize something, someone somewhere will do it, and complain when it 
breaks.  I'd prefer to just not make it possible to make that mistake, 
but at the very least the warning signs need to be very explicit to 
minimize the chance of problems occurring.

> Someone suggested doing away with all public structures in 2.0.  I think
> that would be kind of inconvenient; str->len would become the less
> wieldly svn_string_length(str), etc.

We could have semi-public structures, declared in an internal header 
which is included by the internal library code, so within the svn libs 
we could use str->len, but externally you have to use svn_string_len(str).

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org