On Sun, 2003-12-14 at 17:36, Ben Reser wrote:
> The only way we might break that is by adding a member that causes the
> compiler to pad the struct. Future changes might add more members that
> then remove the need for the pad.
The standard makes this unlikely to ever be a problem. There's a rule
which says that if you put two structures with a common initial sequence
inside a union, then you're allowed to set those fields within one
structure and examine them within another, and it has to work. Although
this guarantee technically only applies to unions, the only practical
way to implement the rule is to ensure that the padding before each
field within a structure never depends on the subsequent fields, only
the previous ones.
> * Per the comment in main.c of the cmdline client it'd be nice if there
> was a place to put svn_config_ensure. svn_client_open is of course just
> such a place now. If were were to set a hard limit that only
> initialization that is *REQUIRED* for the client to do (as
> svn_config_ensure is in this case) could go in the svn_client_open
> function then it probably would be okay.
I'm not sure that svn_config_ensure is really required. If you want to
fill in ctx.config with your own configuration data, I think that's
allowed.
On the patch:
> - svn_client_ctx_t ctx = { 0 };
> + svn_client_ctx_t *ctx = NULL;
Don't initialize the pointer to an invalid value; all that serves to do
is defeat the compiler's logic for determining whether the pointer is
used before it's initialized to a valid value.
> + svn_client_open(&ctx,pool);
We always put a space after commas, and in this file we put a space
before the open paren.
(tools/examples/minimal_client.c has the same pair of problems.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 15 00:12:23 2003