From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org,
Fabrice Fontaine <fontaine.fabrice@gmail.com>
Subject: Re: [PATCH] git-compat-util: avoid redefining system function names
Date: Wed, 7 Dec 2022 15:33:59 +0700 [thread overview]
Message-ID: <Y5BP95xjaA/9C70Q@debian.me> (raw)
In-Reply-To: <Y4sCfRdWAzjqw7cq@debian.me>
[-- Attachment #1: Type: text/plain, Size: 2583 bytes --]
On Sat, Dec 03, 2022 at 03:02:05PM +0700, Bagas Sanjaya wrote:
> On Fri, Dec 02, 2022 at 06:05:38AM -0500, Jeff King wrote:
> > -- >8 --
> > Subject: [PATCH] git-compat-util: undefine system names before redeclaring
> > them
> >
> > When we define a macro to point a system function (e.g., flockfile) to
> > our custom wrapper, we should make sure that the system did not already
> > define it as a macro. This is rarely a problem, but can cause
> > compilation failures if both of these are true:
> >
> > - we decide to define our own wrapper even though the system provides
> > the function; we know this happens at least with uclibc, which may
> > declare flockfile, etc, without _POSIX_THREAD_SAFE_FUNCTIONS
> >
> > - the system version is declared as a macro; we know this happens at
> > least with uclibc's version of getc_unlocked()
> >
> > So just handling getc_unlocked() would be sufficient to deal with the
> > real-world case we've seen. But since it's easy to do, we may as well be
> > defensive about the other macro wrappers added in the previous patch.
> >
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> > There may be other similar cases lurking throughout the code base, but I
> > don't think it's worth anybody's time to go looking for them. If one of
> > them triggers on a real platform, we can deal with it then.
> >
> > git-compat-util.h | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/git-compat-util.h b/git-compat-util.h
> > index 83ec7b7941..76e4b11131 100644
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -346,6 +346,7 @@ static inline int git_setitimer(int which UNUSED,
> > struct itimerval *newvalue UNUSED) {
> > return 0; /* pretend success */
> > }
> > +#undef setitimer
> > #define setitimer(which,value,ovalue) git_setitimer(which,value,ovalue)
> > #endif
> >
> > @@ -1480,6 +1481,9 @@ static inline void git_funlockfile(FILE *fh UNUSED)
> > {
> > ; /* nothing */
> > }
> > +#undef flockfile
> > +#undef funlockfile
> > +#undef getc_unlocked
> > #define flockfile(fh) git_flockfile(fh)
> > #define funlockfile(fh) git_funlockfile(fh)
> > #define getc_unlocked(fh) getc(fh)
>
> The warnings gone away, thanks!
>
> For this patch and the previous one [1],
>
> Tested-by: Bagas Sanjaya <bagasdotme@gmail.com>
>
> [1]: https://lore.kernel.org/git/Y4fH4rhcSztHwKvK@coredump.intra.peff.net/
>
PING?
Is your patch ready for v2.39?
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-12-07 8:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-25 9:23 [PATCH] git-compat-util.h: Fix build without threads Bagas Sanjaya
2022-11-25 23:47 ` Ævar Arnfjörð Bjarmason
2022-11-28 5:04 ` Jeff King
2022-11-29 3:30 ` Bagas Sanjaya
2022-11-29 3:46 ` Bagas Sanjaya
2022-11-28 5:01 ` Jeff King
2022-11-30 21:15 ` [PATCH] git-compat-util: avoid redefining system function names Jeff King
2022-12-02 10:05 ` Bagas Sanjaya
2022-12-02 11:05 ` Jeff King
2022-12-03 8:02 ` Bagas Sanjaya
2022-12-07 8:33 ` Bagas Sanjaya [this message]
2022-12-07 13:00 ` Jeff King
2022-12-02 11:31 ` Ævar Arnfjörð Bjarmason
2022-12-02 22:50 ` 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=Y5BP95xjaA/9C70Q@debian.me \
--to=bagasdotme@gmail.com \
--cc=fontaine.fabrice@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/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.