git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsayjones.plus.com>
To: Danh Doan <congdanhqx@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 2/4] compat/regex: include alloca.h before undef it
Date: Sun, 26 Apr 2020 17:17:56 +0100	[thread overview]
Message-ID: <e9163e0d-2572-e7e0-6aa3-09ce04750b22@ramsayjones.plus.com> (raw)
In-Reply-To: <20200426005451.f7pyoiijgbk4hpsj@danh.dev>



On 26/04/2020 01:54, Danh Doan wrote:
> On 2020-04-25 21:28:05+0100, Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:
[snip]
>> OK, I had a quick look at the <alloca.h> header file on a glibc
>> system (linux) and new-lib system (cygwin) and they both do
>> (more or less) the same thing: first #undef alloca, and then
>> if being compiled by gcc, define alloca(size) to be __builtin_alloca(size).
> 
> musl people don't do that.
> They just go ahead define it, if any other header file requires
> alloca, they will include alloca.h
> 
>> So, even if <alloca.h> is #included after regex.c:66, it wouldn't
>> be a problem. Since I don't have access to a musl based system,
>> I don't know what that system header is doing.
> 
> musl's alloca.h is available here:
> 
> https://git.musl-libc.org/cgit/musl/tree/include/alloca.h

Hmm, OK, so that partly explains the problem. I wonder if the
musl guys would accept a bug report?

>> However, I said *even if* above, because I don't see why it is trying
>> to #include <alloca.h> in the first place! ;-)
> 
> I looked into my system again. The inclusion chain is:
> 
> compat/regex/regex.c:77
> `-> compat/regex/regex_internal.h:26
>     `-> /usr/include/stdlib.h:138 [*1*]
> 
> [*1*]: https://git.musl-libc.org/cgit/musl/tree/include/stdlib.h#n137
> 
> I don't know why _GNU_SOURCE and/or _BSD_SOURCE is defined.

... and this explains the main cause. Hmm, as you say, why are
one (or both) of those pp variables set. :(

[snip] 
>> BTW, why are you compiling with NO_REGEX set anyway?
> 
> Because I use musl-libc, and musl-libc doesn't have StartEnd

Ah, OK. ;-)

Well, even if the musl project accepted a PR and provided a fix, that
will not help you in the short term! :D

Hmm, whatever patch you decide to send (even the original one) I think
you need to add an explanation of the problem to the commit message,
including why the patch provides a solution. (You don't have to type
a novel - see commit bd8f005583 :-P ).

I haven't thought about this too much, but some options:

  - iff the musl library sets some kind of identifying pp variable
    (_MUSL_LIBC_ or somesuch - I haven't looked), then you could
    make the '#include <alloca.h>' conditional on that variable.
    This has the benefit of making it obvious to people reading the
    code that this is specific to musl-libc.

  - you could simply remove that '#ifdef GAWK' block completely (Lines
    64->67). We set GAWK and NO_MBSUPPORT  unconditionally in the Makefile
    so that it compiles (see commit a997bf423d), but these particular
    lines simply reflect the gawk projects dislike of alloca (along with
    the desire to catch any attempts to add new calls which are not protected
    by HAVE_ALLOCA). Given that we are very unlikely to add new calls ...

  - change the conditional on this block to (totally untested, just typing
    into my email client) '#if defined(GAWK) && defined(HAVE_ALLOCA)'.
    This should work, but it does disable the 'catch any attempts to add
    new _unintentional_ calls' aspect of that block; so you may as well
    remove it ...

Just some 'off the top of my head ideas', ... ;-)

ATB,
Ramsay Jones



  parent reply	other threads:[~2020-04-26 16:18 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-23 13:47 [PATCH 0/4] fix make sparse warning Đoàn Trần Công Danh
2020-04-23 13:47 ` [PATCH 1/4] C: s/0/NULL/ for pointer type Đoàn Trần Công Danh
2020-04-24  0:39   ` Ramsay Jones
2020-04-24  0:54     ` Junio C Hamano
2020-04-24  1:09       ` Danh Doan
2020-04-24  1:54         ` Junio C Hamano
2020-05-14 21:37       ` Luc Van Oostenryck
2020-04-23 13:47 ` [PATCH 2/4] compat/regex: silence `make sparse` warning Đoàn Trần Công Danh
2020-04-24  0:51   ` Ramsay Jones
2020-04-24  1:04     ` Danh Doan
2020-04-23 13:47 ` [PATCH 3/4] graph.c: limit linkage of internal variable Đoàn Trần Công Danh
2020-04-24  0:52   ` Ramsay Jones
2020-04-23 13:47 ` [PATCH 4/4] progress.c: silence cgcc suggestion about internal linkage Đoàn Trần Công Danh
2020-04-24  0:58   ` Ramsay Jones
2020-04-24  5:54     ` Jeff King
2020-04-23 13:47 ` [PATCH 5/4] fmt-merge-msg.c: fix `make sparse` on next Đoàn Trần Công Danh
2020-04-23 23:10 ` [PATCH 0/4] fix make sparse warning Ramsay Jones
2020-04-23 23:58   ` Danh Doan
2020-04-24 16:38     ` Ramsay Jones
2020-04-24 15:12 ` [PATCH v2 0/4] Fix Sparse Warning Đoàn Trần Công Danh
2020-04-24 15:12   ` [PATCH v2 1/4] test-parse-pathspec-file.c: s/0/NULL/ for pointer type Đoàn Trần Công Danh
2020-04-24 15:12   ` [PATCH v2 2/4] compat/regex: include alloca.h before undef it Đoàn Trần Công Danh
2020-04-24 16:56     ` Ramsay Jones
2020-04-24 17:09       ` Danh Doan
2020-04-24 18:29         ` Ramsay Jones
2020-04-24 22:34           ` Danh Doan
2020-04-25 20:28             ` Ramsay Jones
2020-04-26  0:54               ` Danh Doan
2020-04-26  1:10                 ` Danh Doan
2020-04-26 16:17                 ` Ramsay Jones [this message]
2020-04-26 19:38                   ` Ramsay Jones
2020-04-26 22:37                     ` Junio C Hamano
2020-04-27  1:08                   ` Danh Doan
2020-04-27 16:28                     ` Ramsay Jones
2020-04-27 16:46                       ` Danh Doan
2020-04-27 17:21                         ` Ramsay Jones
2020-04-24 15:12   ` [PATCH v2 3/4] graph.c: limit linkage of internal variable Đoàn Trần Công Danh
2020-04-24 15:12   ` [PATCH v2 4/4] progress.c: silence cgcc suggestion about internal linkage Đoàn Trần Công Danh
2020-04-24 16:40   ` [PATCH v2 0/4] Fix Sparse Warning Ramsay Jones
2020-04-25 13:13 ` [PATCH 0/4] fix make sparse warning Johannes Schindelin
2020-04-26  3:32   ` Danh Doan
2020-04-26 16:24     ` Ramsay Jones
2020-05-01 20:02       ` Johannes Schindelin
2020-04-27 14:22 ` [PATCH v3 0/4] Partial fix `make sparse` Đoàn Trần Công Danh
2020-04-27 14:22   ` [PATCH v3 1/4] test-parse-pathspec-file.c: s/0/NULL/ for pointer type Đoàn Trần Công Danh
2020-04-27 14:22   ` [PATCH v3 2/4] compat/regex: move stdlib.h up in inclusion chain Đoàn Trần Công Danh
2020-04-27 16:41     ` Ramsay Jones
2020-04-27 14:22   ` [PATCH v3 3/4] graph.c: limit linkage of internal variable Đoàn Trần Công Danh
2020-04-27 14:22   ` [PATCH v3 4/4] progress.c: silence cgcc suggestion about internal linkage Đoàn Trần Công Danh
2020-05-01 20:09     ` Johannes Schindelin
2020-04-27 16:35   ` [PATCH v3 0/4] Partial fix `make sparse` Ramsay Jones

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=e9163e0d-2572-e7e0-6aa3-09ce04750b22@ramsayjones.plus.com \
    --to=ramsay@ramsayjones.plus.com \
    --cc=congdanhqx@gmail.com \
    --cc=git@vger.kernel.org \
    /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).