-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/ 2/12 10:47 AM, Keith Packard wrote:
> Alan Coopersmith <[email protected]> writes:
>
> Ok, I like the general plan here, but there are a mish-mash of styles which
> doesn't really seem neater than the original code.
>
> If we can, indeed, use this form:
>
>> + + reply = (xQueryTreeReply) { + .type = X_Reply, +
>> .sequenceNumber = client->sequence, + .root =
>> pWin->drawable.pScreen->root->drawable.id, + .parent =
>> (pWin->parent) ? pWin->parent->drawable.id : (Window) None + };
>
> then I'd like to see that used uniformly as it will eliminate the need to
> create artificial blocks to place new declarations and initializers in, and
> will make the patch a lot easier to read -- you'd be replacing a sequence
> of assignment statements with a single struct assignment.
I can take a pass over to see about converting all to that style. Would
you even want to see it used where the blocks were more natural, such as
if (rc != Success && rc != MappingSuccess && rc != MappingFailed &&
rc != MappingBusy)
return rc;
- -
- - rep.success = rc;
- -
- - WriteReplyToClient(client, sizeof(xSetModifierMappingReply), &rep);
- - return Success;
+ else {
+ xSetModifierMappingReply rep = {
+ .type = X_Reply,
+ .success = rc,
+ .sequenceNumber = client->sequence,
+ .length = 0
+ };
+ WriteReplyToClient(client, sizeof(xSetModifierMappingReply), &rep);
+ return Success;
+ }
}
I did like the scope limiting feature of blocks like that, though that's
more about developer efficiency (both in code reading and preventing
premature use of fields before the initialization block) than code/compiler
efficiency.
- --
-Alan Coopersmith- [email protected]
Oracle Solaris Engineering - http://blogs.oracle.com/alanc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/zT4YACgkQovueCB8tEw5v3QCgi/QSeedkhFKH04dkV6ovdTxy
+30An1TyrI7KGwfERGoLl2OcePQIIUFa
=4EjH
-----END PGP SIGNATURE-----
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
