From: Jonathan Nieder <jrnieder@gmail.com>
To: Thomas Rast <tr@thomasrast.ch>
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
git@vger.kernel.org
Subject: Re: [PATCH v2] commit-slab: declare functions "static inline"
Date: Mon, 25 Nov 2013 12:35:57 -0800 [thread overview]
Message-ID: <20131125203557.GP4212@google.com> (raw)
In-Reply-To: <87wqjw1bm5.fsf@thomasrast.ch>
Thomas Rast wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Thomas Rast wrote:
>>> This shuts up compiler warnings about unused functions.
>>
>> If that is the only goal, I think it would be cleaner to use
>>
>> #define MAYBE_UNUSED __attribute__((__unused__))
>>
>> static MAYBE_UNUSED void init_ ...
>>
>> like was done in the vcs-svn/ directory until cba3546 (drop obj_pool,
>> 2010-12-13) et al.
>>
>> I haven't thought carefully about whether encouraging inlining here
>> (or encouraging the reader to think of these functions as inline) is a
>> good or bad change.
>
> Hmm.
>
> I actually had this idea after seeing the same trick in khash.h. Is
> __atribute__((__unused__)) universal? If so, maybe we could apply the
> same also to khash? If not, I'd rather go with the inline.
The khash functions are very small, so it very well may make sense for
them to be inline.
git-compat-util.h (or compat/msvc.h) defines __attribute__(x) to an
empty sequence of tokens except on HP C and gcc. Attribute unused has
existed at least since GCC 2.95.
Unfortunately HP C doesn't support attribute __unused__. :(
http://h21007.www2.hp.com/portal/download/files/unprot/aCxx/Online_Help/pragmas.htm#Attributes
On the bright side, it would be easy to work around using a
conditional definition of MAYBE_UNUSED for the sake of HP C. From
August 2010 until March 2011 nobody noticed.
Jonathan
next prev parent reply other threads:[~2013-11-25 20:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 19:01 [PATCH 0/2] commit-slab cleanups Thomas Rast
2013-11-25 19:02 ` [PATCH 1/2] commit-slab: document clear_$slabname() Thomas Rast
2013-11-25 20:24 ` Jonathan Nieder
2013-11-29 19:35 ` Thomas Rast
2013-11-25 20:39 ` Junio C Hamano
2013-11-27 10:39 ` Eric Sunshine
2013-11-25 19:02 ` [PATCH 2/2] commit-slab: declare functions "static inline" Thomas Rast
2013-11-25 19:36 ` Junio C Hamano
2013-11-25 19:53 ` Thomas Rast
2013-11-25 20:04 ` [PATCH v2] " Thomas Rast
2013-11-25 20:12 ` Jonathan Nieder
2013-11-25 20:15 ` Thomas Rast
2013-11-25 20:35 ` Jonathan Nieder [this message]
2013-11-25 20:33 ` Junio C Hamano
2013-11-25 20:23 ` Junio C Hamano
2013-12-01 10:36 ` [PATCH 2/2] " Duy Nguyen
2013-12-01 20:41 ` [PATCH] commit-slab: sizeof() the right type in xrealloc Thomas Rast
2013-12-02 15:35 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131125203557.GP4212@google.com \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=tr@thomasrast.ch \
/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.
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 NNTP newsgroup(s).