[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: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-01-22 02:15:36 CET

Heh! Thanks for the lesson, Greg. I had forgotten about the union
requirements (though I think you've pointed them out here before),
which make it even more likely that the cast would always work in
practice.

Looks like Garrett is going to remove the cast, anyway.

-K

Greg Hudson <ghudson@MIT.EDU> writes:
> 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.