From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: tboegi@web.de, GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH 2/6] path: Make the 'get_st_mode_bits' symbol a file static
Date: Mon, 29 Apr 2013 23:53:08 +0100 [thread overview]
Message-ID: <517EF9D4.50105@ramsay1.demon.co.uk> (raw)
In-Reply-To: <7vip36qxui.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> On MinGW, sparse issues an "'get_st_mode_bits' not declared. Should
>> it be static?" warning. The MinGW and MSVC builds do not see the
>> declaration of this function, within git-compat-util.h, due to it's
>> placement within an preprocessor conditional. (So, one solution would
>> be to simply move the declaration to the top level of the header.)
>
> Well, the idea was that the user of this function in path.c will
> call get_st_mode_bits(), and whatever platform that provides a
> replacement implementation would do
>
> #define get_st_mode_bits(a,b) cygwin_get_st_mode_bits((a),(b))
>
> so that the calling site in path.c will end up calling that
> replacement implementation. So if anything get_st_mode_bits()
> declaration may want to go at the _end_ (not top) after including
> all the compatibility crufts.
>
> We could make the declaration static to path.c, but then nobody
> other than path.c would be able to make use of it in the future,
> and we'll have the same discussion when somebody wants to hoist the
> declaration to git-compat-util.h, no?
I don't have a problem with keeping the declaration in git-compat-util.h
(after moving it so that the MinGW and MSVC builds can see it, of course)
if you would rather do that.
However, I'm always a little wary when I hear someone say "this may be
useful to others in the future, so lets do X to make it easier ...".
I have noticed that, much more often than not, that future user never
does materialise ... ;-)
Having said that ...
Back in 2011, when I was trying to fix t7606-merge-custom.sh (see
commit b8a9733377, "help.c: Fix detection of custom merge strategy
on cygwin", 16-06-2011), I had a patch that looked very similar to
the solution Torsten has arrived at here! (The main difference was
that I called stat() rather than lstat() to get the mode bits).
I decided to go with the simpler solution in commit b8a9733377.
ATB,
Ramsay Jones
next prev parent reply other threads:[~2013-04-29 23:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-27 18:42 [PATCH 2/6] path: Make the 'get_st_mode_bits' symbol a file static Ramsay Jones
2013-04-28 2:26 ` Eric Sunshine
2013-04-28 6:02 ` Torsten Bögershausen
2013-04-28 11:32 ` Torsten Bögershausen
2013-04-29 21:57 ` Ramsay Jones
2013-04-28 19:06 ` Junio C Hamano
2013-04-29 22:53 ` Ramsay Jones [this message]
2013-04-30 17:00 ` 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=517EF9D4.50105@ramsay1.demon.co.uk \
--to=ramsay@ramsay1.demon.co.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tboegi@web.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.