From: Jeff King <peff@peff.net>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Michael Haggerty <mhagger@alum.mit.edu>,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH 8/8] Enable GIT_DEBUG_MEMCHECK on git_pathname()
Date: Thu, 17 Nov 2011 20:27:15 -0500 [thread overview]
Message-ID: <20111118012715.GA7826@sigill.intra.peff.net> (raw)
In-Reply-To: <CACsJy8A25SyLVKv8GwkYaHBJwU5tHqgdJK6L-upF9HWseFzCtQ@mail.gmail.com>
On Fri, Nov 18, 2011 at 08:12:27AM +0700, Nguyen Thai Ngoc Duy wrote:
> > Older compilers will probably barf on the variable-argument macros.
>
> Anyway to detect if __VA_ARGS__ is supported at compile time? I guess
> #ifdef __GNUC__ is the last resort.
You can check "#if __STDC_VERSION__ >= 19901L", but that will of course
only tell you whether you have C99; older gcc (and possibly other
compilers) supported __VA_ARGS__ even before it was standardized.
But more annoying is that there isn't a great fallback to __VA_ARGS__.
If you can't use it, then every callsite has to have the same number of
arguments. So it's not like you can localize the fallback code to just
the definition.
Unless you really need macro-like behavior, you're probably better off
using a variadic function and making it a static inline on platforms
which can do so.
> notes-merge.c introduces __VA_ARGS__ since v1.7.4 so we may want to do
> something there too.
I hadn't noticed. That definitely violates our usual rules about
portability. That usage can easily be turned into an inline function.
However, since nobody has complained in the past year, it makes me
wonder if we are overly conservative (my guess is that people on crazy
old compilers just don't keep up with git. Which maybe means they aren't
worth worrying about. But who knows).
-Peff
next prev parent reply other threads:[~2011-11-18 1:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-17 9:32 [PATCH 0/8] nd/resolve-ref v2 Nguyễn Thái Ngọc Duy
2011-11-17 9:32 ` [PATCH 1/8] Convert many resolve_ref() calls to read_ref*() and ref_exists() Nguyễn Thái Ngọc Duy
2011-11-17 9:32 ` [PATCH 2/8] Rename resolve_ref() to resolve_ref_unsafe() Nguyễn Thái Ngọc Duy
2011-11-17 9:32 ` [PATCH 3/8] Re-add resolve_ref() that always returns an allocated buffer Nguyễn Thái Ngọc Duy
2011-11-17 9:32 ` [PATCH 4/8] cmd_merge: convert to single exit point Nguyễn Thái Ngọc Duy
2011-11-17 10:39 ` Ramkumar Ramachandra
2011-11-17 10:44 ` Jonathan Nieder
2011-11-17 9:32 ` [PATCH 5/8] Use resolve_ref() instead of resolve_ref_unsafe() Nguyễn Thái Ngọc Duy
2011-11-17 9:32 ` [PATCH 6/8] Convert resolve_ref_unsafe+xstrdup to resolve_ref Nguyễn Thái Ngọc Duy
2011-11-17 10:22 ` Ramkumar Ramachandra
2011-11-18 0:57 ` Nguyen Thai Ngoc Duy
2011-11-17 9:32 ` [PATCH 7/8] Guard memory overwriting in resolve_ref_unsafe's static buffer Nguyễn Thái Ngọc Duy
2011-11-17 9:32 ` [PATCH 8/8] Enable GIT_DEBUG_MEMCHECK on git_pathname() Nguyễn Thái Ngọc Duy
2011-11-17 10:35 ` Ramkumar Ramachandra
2011-11-17 13:42 ` Jeff King
2011-11-18 1:12 ` Nguyen Thai Ngoc Duy
2011-11-18 1:27 ` Jeff King [this message]
2011-11-18 1:36 ` Jonathan Nieder
2011-11-18 1:50 ` Nguyen Thai Ngoc Duy
2011-11-18 2:06 ` Jeff King
2011-11-18 1:27 ` Jonathan Nieder
2011-11-18 6:16 ` Johan Herland
2011-11-18 6:52 ` Jonathan Nieder
2011-11-18 7:35 ` Junio C Hamano
2011-11-18 12:50 ` Bernhard R. Link
2011-11-17 10:39 ` [PATCH 0/8] nd/resolve-ref v2 Jonathan Nieder
2011-12-06 14:07 ` Nguyen Thai Ngoc Duy
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=20111118012715.GA7826@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=artagnon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.com \
/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).