[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: path canonicalization problem (issue #559)

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-01-22 01:39:52 CET

On Mon, 2002-01-21 at 18:15, Karl Fogel wrote:
> Garrett Rooney <rooneg@electricjellyfish.net> writes:
> > > > + if (svn_path_is_url ((const svn_string_t *)path))
> > >
> > > This cast relies on the members of svn_string_t being ordered the same
> > > as svn_stringbuf_t. It's true at present, but is it guaranteed?
>
> Even if they are ordered the same (which I believe is guaranteed),
> they may not be padded the same. Structure members may be padded for
> alignment purposes, therefore a cast like this is technically not
> valid.

Your conclusion is correct, I believe, but your reasoning is perhaps a
little simplified. Consider:

  * If a union has two structure members which share a common initial
sequence, you can assign to fields of the common initial sequence in one
structure member and inspect those fields of the other. (C89, section
3.3.2.3.)

  * A pointer to a union can be converted to a pointer to any of its
members via a cast. (C89, section 3.5.2.1.) Same for a structure and
its first member, incidentally.

Given these two facts, it is very hard to imagine an implementation
which would disallow casting svn_stringbuf_t to svn_string_t and using
the contents; such an implementation would have to use some serious
magic to make unions work. But, I could find no explicit guarantee in
the standard that you can cast pointers between structures with common
initial sequences. If we really really wanted to make this kind of cast
possible, we would do:

  typedef struct { char *data; apr_size_t len; } svn_string_t;
  typedef struct { svn_string_t str;
                   apr_size_t blocksize;
                   apr_pool_t *pool; } svn_stringbuf_t;

(but not in that style, of course). But we would be sacrificing the
const-ness of svn_string_t's data member, so I don't really recommend
it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:57 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.