John Szakmeister <john@xxxxxxxxxxxxxxx> writes:
> Signed-off-by: John Szakmeister <john@xxxxxxxxxxxxxxx>
> ---
> The gnome-keyring credential backend had a number of coding style
> violations. I believe this fixes all of them.
>
> .../gnome-keyring/git-credential-gnome-keyring.c | 55 ++++++++++------------
> 1 file changed, 25 insertions(+), 30 deletions(-)
>
> diff --git a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
> index 635c96b..1613404 100644
> --- a/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
> +++ b/contrib/credential/gnome-keyring/git-credential-gnome-keyring.c
> @@ -95,9 +95,9 @@ static const char* gnome_keyring_result_to_message(GnomeKeyringResult result)
>
> static void gnome_keyring_done_cb(GnomeKeyringResult result, gpointer user_data)
> {
> - gpointer *data = (gpointer*) user_data;
> - int *done = (int*) data[0];
> - GnomeKeyringResult *r = (GnomeKeyringResult*) data[1];
> + gpointer *data = (gpointer *) user_data;
> + int *done = (int *) data[0];
> + GnomeKeyringResult *r = (GnomeKeyringResult *) data[1];
I thought we cast without SP after the (typename), i.e.
gpointer *data = (gpointer *)user_data;
It could be argued that a cast that turns a "void *" to a pointer to
another type can go, as Felipe noted, but I think that is better
done in a separate patch, perhaps as a follow-up to this "small
stylistic clean-ups".
I said "it could be argued" above, because I am on the fence on that
change. If this were not using a type "gpointer", whose point is to
hide what the actual implementation of that type is, but a plain
vanilla "void *", then I would not have any doubt. But it feels
wrong to look behind that deliberate "gpointer" abstraction and take
advantage of the knowledge that it happens to be implemented as
"void *" (and if we do not start from that knowledge, losing the
cast is a wrong change).
So...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html