git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Phil Hord <phil.hord@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"René Scharfe" <rene.scharfe@lsrfire.ath.cx>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	git@vger.kernel.org
Subject: Re: [PATCH] fmt-merge-msg: show those involved in a merged series
Date: Tue, 13 Mar 2012 17:03:57 -0400	[thread overview]
Message-ID: <20120313210357.GC27436@sigill.intra.peff.net> (raw)
In-Reply-To: <CABURp0oVn3s27Rtq2JQeLBgcXq1-R-=0qawcXVMxZ8qgOeZGkQ@mail.gmail.com>

On Mon, Mar 12, 2012 at 05:37:57PM -0400, Phil Hord wrote:

> Subject: [PATCH] Appease compiler pedantry with an extra cast
> 
> Recently git repurposed a pointer as an integer to hold some
> counter which git fancies.
> 
> Casting directly from 'pointer' to 'int' ((int)(void*)&x) causes a
> possible size mismatch because pointers can be bigger than ints.
> In such a situation, the compiler complains:
> 
>    warning: cast from pointer to integer of different size
>             [-Wpointer-to-int-cast]

Yeah, I've been seeing the same warning on my x86_64 box, and came up
with the same fix. However...

> Cast the value through intptr_t first to quell compiler complaints
> about how this gun appears to be aimed near our feet.  Then cast this
> value to an int; this path assures the compiler we are smarter than we
> look, or at least that we intend to aim the gun this way for a reason.

This feels so hacky.  One of the callsites does:

    elem->util = (void*)((intptr_t)(util_as_int(elem) + 1));

which will truncate the value down to an int before replacing it back in
the void pointer. And that truncation is ultimately what the compiler is
warning about, and what we are sneaking around with the extra cast
(because casting between integer sizes of different types is OK, even
though it can cause truncation).

I don't think the truncation is a problem in practice, but it just feels
like we are not just silencing an over-zealous compiler, but actually
burying type-size assumption behind a set of four (4!) casts.

I wonder if we would be happier to declare the "util" field of
string_list as a union. Obviously that provides no safety that we read
the correct item out of the union, but that is no worse than the
situation with all of these casts, and I suspect the result would be
much more obvious and readable.

The downside is that all current users of the "util" field would need
s/util/&.ptr/ or similar to dereference the pointer field.

-Peff

  reply	other threads:[~2012-03-13 21:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-05  3:17 A possible fmt-merge-msg update? Junio C Hamano
2012-03-05  5:24 ` Linus Torvalds
2012-03-05 19:04   ` Junio C Hamano
2012-03-05 20:33     ` Linus Torvalds
2012-03-05 21:34       ` [PATCH] fmt-merge-msg: show those involved in a merged series Junio C Hamano
2012-03-05 21:46         ` Linus Torvalds
2012-03-05 21:49           ` Junio C Hamano
2012-03-07 21:22         ` René Scharfe
2012-03-07 21:59           ` Junio C Hamano
2012-03-08 17:46             ` René Scharfe
2012-03-08 19:18               ` Junio C Hamano
2012-03-08 21:31                 ` Junio C Hamano
2012-03-12 21:37                 ` Phil Hord
2012-03-13 21:03                   ` Jeff King [this message]
2012-03-14  3:44                     ` Junio C Hamano
2012-03-14 19:12                     ` Phil Hord
2012-03-12  7:11         ` Jonathan Nieder
2012-03-13  1:55           ` Junio C Hamano
2012-03-13  5:23             ` Jonathan Nieder
2012-03-13  5:45               ` Junio C Hamano
2012-03-13  7:27             ` Johannes Sixt
2012-03-13 18:26               ` Junio C Hamano
2012-03-14  6:37                 ` Johannes Sixt
2012-03-14 20:34                   ` Junio C Hamano
2012-03-13 18:28               ` [PATCH v2 1/1] " Junio C Hamano
2012-05-11 10:31             ` [PATCH/RFC] fmt-merge-msg: add a blank line after people info Jonathan Nieder
2012-05-11 22:46               ` Junio C Hamano
2012-05-11 23:20                 ` Linus Torvalds
2012-05-14 18:31                   ` Junio C Hamano
2012-05-15 20:24                     ` Junio C Hamano
2012-05-16  2:02                       ` Linus Torvalds
2012-05-16 17:28                         ` Junio C Hamano
2012-06-06 20:27                 ` Jonathan Nieder
2012-06-06 20:46                   ` Jonathan Nieder
2012-06-06 21:11                     ` Junio C Hamano
2012-03-06  7:59       ` A possible fmt-merge-msg update? Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120313210357.GC27436@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=phil.hord@gmail.com \
    --cc=rene.scharfe@lsrfire.ath.cx \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).