git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] git-compat-util: Avoid strcasecmp() being inlined

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Sep 18, 2013, 12:19 UTC
Message-ID
<CA+55aFwJQ7yo3N3rdAz2=o9Zxxt4ascF5kzvB6-YHL+HXbz7ug@mail.gmail.com>
In-Reply-To
<CAHGBnuMh9wqe6mhLyqbPAGJUEEH7cA2LZPuCQK8VD=NU2ix3Pg@mail.gmail.com>

On Wed, Sep 18, 2013 at 5:43 AM, Sebastian Schuberth <sschuberth@gmail.com> wrote:

>
> My feeling is that Linus' reaction was more about that this
> work-around is even necessary (and MinGW is buggy) rather than
> applying it to git-compat-util.h and not elsewhere.

So I think it's an annoying MinGW bug, but the reason I dislike the "no-inline" approach is two-fold:

 - it's *way* too intimate with the bug.
   When you have a bug like this, the *last* thing you want to do is
to make sweet sweet love to it, and get really involved with it.
   You want to say "Eww, what a nasty little bug, I don't want to have
anything to do with you".
   And quite frankly, delving into the details of exactly *what* MinGW
does wrong, and defining magic __NO_INLINE__ macros, knowing that that
is the particular incantation that hides the MinGW bug, that's being
too intimate. That's simply a level of detail that *nobody* should
ever have to know.
   The other patch (having just a wrapper function) doesn't have those
kinds of intimacy issues. That patch just says "MinGW is buggy and
cannot do this function uninlined, so we wrap it". Notice the lack of
detail, and lack of *interest* in the exact particular pattern of the
bug.

The other reason I'm not a fan of the __NO_INLINE__ approach is even more straightforward:

 - Why should we disable the inlining of everything in <string.h> (and
possibly elsewhere too - who the hell knows what __NO_INLINE__ will do
to other header files), when in 99% of all the cases we don't care,
and in fact inlining may well be good and the right thing to do.

So the __NO_INLINE__ games seem to be both too big of a hammer, and too non-specific, and at the same time it gets really intimate with MinGW in unhealthy ways.

If you know something is diseased, you keep your distance, you don't try to embrace it.

Show 5 quoted lines
> I tried to put the __NO_INLINE__ stuff in compat/mingw.h but failed,
> it involved the need to shuffle includes in git-compat-util.h around
> because winsock2.h already seems to include string.h, and I did not
> find a working include order. So I came up with the following, do you
> like that better?
Ugh, so now that patch is fragile, so we have to complicate it even more.

Really, just make a wrapper function. It doesn't even need to be conditional on MinGW. Just a single one-liner function, with a comment above it that says "MinGW is broken and doesn't have an out-of-line copy of strcasecmp(), so we wrap it here".

No unnecessary details about internal workings of a buggy MinGW header file. No complexity. No subtle issues with include file ordering. Just a straightforward workaround that is easy to explain.

                        Linus
Previous: Sebastian SchuberthNext: Jonathan Nieder
Message 37 of 48 in “git-compat-util: Avoid strcasecmp() being inlined”
  1. git-compat-util: Avoid strcasecmp() being inlinedSebastian Schuberth, Sep 11, 2013
  2. Jonathan NiederSep 11, 2013
  3. Jeff KingSep 11, 2013
  4. Piotr KrukowieckiSep 19, 2013
  5. Sebastian SchuberthSep 11, 2013
  6. Jeff KingSep 11, 2013
  7. Sebastian SchuberthSep 12, 2013
  8. John KeepingSep 12, 2013
  9. Junio C HamanoSep 12, 2013
  10. Jeff KingSep 12, 2013
  11. Junio C HamanoSep 12, 2013
  12. Jonathan NiederSep 12, 2013
  13. Sebastian SchuberthSep 12, 2013
  14. Junio C HamanoSep 12, 2013
  15. Sebastian SchuberthSep 13, 2013
  16. Junio C HamanoSep 13, 2013
  17. Sebastian SchuberthSep 13, 2013
  18. Jonathan NiederSep 12, 2013
  19. Jeff KingSep 12, 2013
  20. Sebastian SchuberthSep 12, 2013
  21. Jeff KingSep 12, 2013
  22. Junio C HamanoSep 12, 2013
  23. Sebastian SchuberthSep 13, 2013
  24. Junio C HamanoSep 13, 2013
  25. Sebastian SchuberthSep 13, 2013
  26. Linus TorvaldsSep 13, 2013
  27. Sebastian SchuberthSep 13, 2013
  28. Junio C HamanoSep 13, 2013
  29. Sebastian SchuberthSep 13, 2013
  30. Junio C HamanoSep 13, 2013
  31. Junio C HamanoSep 13, 2013
  32. Sebastian SchuberthSep 15, 2013
  33. Junio C HamanoSep 17, 2013
  34. Sebastian SchuberthSep 17, 2013
  35. Junio C HamanoSep 17, 2013
  36. Sebastian SchuberthSep 18, 2013
  37. Linus TorvaldsSep 18, 2013
  38. Jonathan NiederSep 12, 2013
  39. Sebastian SchuberthSep 19, 2013
  40. Junio C HamanoSep 11, 2013
  41. Piotr KrukowieckiSep 19, 2013
  42. Jeff KingSep 19, 2013
  43. Junio C HamanoSep 19, 2013
  44. Jeff KingSep 19, 2013
  45. Junio C HamanoSep 19, 2013
  46. Jeff KingSep 20, 2013
  47. Piotr KrukowieckiSep 20, 2013
  48. Jeff KingSep 24, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.