From: Junio C Hamano <gitster@pobox•com>
To: John Keeping <john@keeping•me.uk>
Cc: Sebastian Schuberth <sschuberth@gmail•com>,
Jeff King <peff@peff•net>, Jonathan Nieder <jrnieder@gmail•com>,
Git Mailing List <git@vger•kernel.org>,
Karsten Blees <karsten.blees@gmail•com>
Subject: Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined
Date: Thu, 12 Sep 2013 08:37:08 -0700 [thread overview]
Message-ID: <xmqq61u6qcez.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20130912101419.GY2582@serenity.lan> (John Keeping's message of "Thu, 12 Sep 2013 11:14:19 +0100")
John Keeping <john@keeping•me.uk> writes:
> On Thu, Sep 12, 2013 at 11:36:56AM +0200, Sebastian Schuberth wrote:
>> > Just wondering if that is the root of the problem, or if maybe there is
>> > something else subtle going on. Also, does __CRT_INLINE just turn into
>> > "inline", or is there perhaps some other pre-processor magic going on?
>>
>> This is the function definition from string.h after preprocessing:
>>
>> extern __inline__ int __attribute__((__cdecl__)) __attribute__ ((__nothrow__))
>> strncasecmp (const char * __sz1, const char * __sz2, size_t __sizeMaxCompare)
>> {return _strnicmp (__sz1, __sz2, __sizeMaxCompare);}
>
> I wonder if GCC has changed it's behaviour to more closely match C99.
> Clang as a compatibility article about this sort of issue:
>
> http://clang.llvm.org/compatibility.html#inline
Interesting. The ways the page suggests as fixes are
- change it to a "statis inline";
- remove "inline" from the definition;
- provide an external (non-inline) def somewhere else;
- compile with gnu899 dialect.
But the first two are non-starter, and the third one to force
everybody to define an equivalent implementation is nonsense, for a
definition in the standard header file.
I agree with an earlier conclusion that defining our own wrapper
(with an explanation why such a redundant wrapper exists) is the
best course of action at this point, until the system header is
fixed.
mailmap.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index a7969c4..d36d424 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -52,6 +52,19 @@ static void free_mailmap_entry(void *p, const char *s)
string_list_clear_func(&me->namemap, free_mailmap_info);
}
+/*
+ * On some systems, string.h has _only_ inline definition of strcasecmp
+ * without supplying a non-inline implementation anywhere, which is, eh,
+ * "unusual"; we cannot take an address of such a function to store it in
+ * namemap.cmp. This is here as a workaround---do not assign strcasecmp
+ * directly to namemap.cmp until we know no systems that matter have such
+ * an "unusual" string.h.
+ */
+static int namemap_cmp(const char *a, const char *b)
+{
+ return strcasecmp(a, b);
+}
+
static void add_mapping(struct string_list *map,
char *new_name, char *new_email,
char *old_name, char *old_email)
@@ -75,7 +88,7 @@ static void add_mapping(struct string_list *map,
item = string_list_insert_at_index(map, index, old_email);
me = xcalloc(1, sizeof(struct mailmap_entry));
me->namemap.strdup_strings = 1;
- me->namemap.cmp = strcasecmp;
+ me->namemap.cmp = namemap_cmp;
item->util = me;
}
@@ -237,7 +250,7 @@ int read_mailmap(struct string_list *map, char **repo_abbrev)
int err = 0;
map->strdup_strings = 1;
- map->cmp = strcasecmp;
+ map->cmp = namemap_cmp;
if (!git_mailmap_blob && is_bare_repository())
git_mailmap_blob = "HEAD:.mailmap";
next prev parent reply other threads:[~2013-09-12 15:37 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-11 16:06 [PATCH] git-compat-util: Avoid strcasecmp() being inlined Sebastian Schuberth
2013-09-11 18:29 ` Jonathan Nieder
2013-09-11 19:16 ` Jeff King
2013-09-19 6:04 ` Piotr Krukowiecki
[not found] ` <CAPc5daVt4Q9twub5KyOQqZHx9CwOnkuwA97sXV44fF2j1e5HVg@mail.gmail.com>
2013-09-19 9:47 ` Piotr Krukowiecki
2013-09-19 21:16 ` Jeff King
2013-09-19 22:03 ` Junio C Hamano
2013-09-19 22:05 ` Jeff King
2013-09-19 22:40 ` Junio C Hamano
2013-09-20 3:18 ` Jeff King
2013-09-20 6:21 ` Piotr Krukowiecki
2013-09-24 5:32 ` Jeff King
2013-09-11 19:59 ` Sebastian Schuberth
2013-09-11 21:41 ` Jeff King
2013-09-12 9:36 ` Sebastian Schuberth
2013-09-12 10:14 ` John Keeping
2013-09-12 15:37 ` Junio C Hamano [this message]
2013-09-12 18:20 ` Jeff King
2013-09-12 18:35 ` Junio C Hamano
2013-09-12 18:38 ` Jonathan Nieder
2013-09-12 19:51 ` Sebastian Schuberth
2013-09-12 20:08 ` Junio C Hamano
2013-09-13 12:33 ` Sebastian Schuberth
2013-09-13 14:26 ` Junio C Hamano
2013-09-13 19:34 ` Sebastian Schuberth
2013-09-12 21:36 ` Jonathan Nieder
2013-09-12 19:00 ` Jeff King
2013-09-12 19:46 ` Sebastian Schuberth
2013-09-12 20:22 ` Jeff King
2013-09-12 20:29 ` Junio C Hamano
2013-09-13 12:47 ` Sebastian Schuberth
2013-09-13 14:37 ` Junio C Hamano
2013-09-13 19:53 ` Sebastian Schuberth
2013-09-13 19:56 ` Linus Torvalds
2013-09-13 20:03 ` Sebastian Schuberth
2013-09-13 20:01 ` Junio C Hamano
2013-09-13 20:04 ` Sebastian Schuberth
2013-09-13 22:06 ` Junio C Hamano
2013-09-13 22:35 ` Junio C Hamano
2013-09-15 12:44 ` Sebastian Schuberth
2013-09-17 16:17 ` Junio C Hamano
2013-09-17 19:16 ` Sebastian Schuberth
2013-09-17 21:46 ` Junio C Hamano
2013-09-18 9:43 ` Sebastian Schuberth
2013-09-18 12:19 ` Linus Torvalds
2013-09-12 21:31 ` Jonathan Nieder
2013-09-19 13:47 ` Sebastian Schuberth
2013-09-11 18:39 ` Junio C Hamano
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=xmqq61u6qcez.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=john@keeping$(echo .)me.uk \
--cc=jrnieder@gmail$(echo .)com \
--cc=karsten.blees@gmail$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=sschuberth@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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