All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Stepan Kasal <kasal@ucw.cz>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org,
	Jean-Jacques Lafay <jeanjacques.lafay@gmail.com>
Subject: Re: [PATCH v2] git tag --contains : avoid stack overflow
Date: Wed, 23 Apr 2014 14:05:47 -0700	[thread overview]
Message-ID: <xmqqfvl3ycwk.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20140423205533.GA20582@sigill.intra.peff.net> (Jeff King's message of "Wed, 23 Apr 2014 16:55:33 -0400")

Jeff King <peff@peff.net> writes:

> On Wed, Apr 23, 2014 at 01:48:05PM -0700, Junio C Hamano wrote:
>
>> > I don't think so. The point is that we _must_ use bash here, not any
>> > POSIX shell.
>> 
>> Sorry, but I do not understand.  Isn't what you want "any POSIX
>> shell with 'ulimit -s 64' supported"?
>
> Sure, that would be fine, but the original patch which started this
> thread claimed that bash was required. I had assumed that to be true,
> but it seems like it's not:
>
>>     $ dash -c 'ulimit -s && ulimit -s 64 && ulimit -s'
>>     8192
>>     64
>
> If we are just using the same shell we are already running, then why
> invoke it by name in the first place? IOW, why not:
>
>   run_with_limited_stack () {
> 	(ulimit -s 64 && "$@")
>   }

That is certainly more preferrable than an explicit "run this piece
with $SHELL_PATH".

I think the choice between "Any bash that is on user's PATH" vs "The
shell the user told us to use when working with Git" is a trade-off
between

 - those who choose a shell that does not support "ulimit -s" to
   work with Git (which is fine, because our scripted Porcelains
   would not have any need for that); for these people, this test
   would be skipped unnecessarily if we insist on SHELL_PATH; and

 - those who run on a box without any bash on their PATH, chose a
   shell that is not bash but does support "ulimit -s" as their
   SHELL_PATH to build Git with; for these people, this test would
   be skipped unnecessarily if we insist on "bash".

and I do not think of a good reason to favor one over the other.

If I have to pick, I'd take your "don't name any shell, and let the
current one run it" approach, solely for the simplicity of the
solution (it ends up favoring the latter class of people as a
side-effect, though).

  reply	other threads:[~2014-04-23 21:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-16 14:15 [PATCH] git tag --contains : avoid stack overflow Stepan Kasal
2014-04-16 15:46 ` Jeff King
2014-04-17 17:31   ` Johannes Schindelin
2014-04-17 21:32     ` Jeff King
2014-04-17 21:52       ` Johannes Schindelin
2014-04-17 21:58         ` Jeff King
2014-04-23  7:53           ` [PATCH v2] " Stepan Kasal
2014-04-23 14:28             ` Johannes Schindelin
2014-04-23 15:45               ` Stepan Kasal
2014-04-23 19:12             ` Junio C Hamano
2014-04-23 19:16               ` Jeff King
2014-04-23 20:48                 ` Junio C Hamano
2014-04-23 20:55                   ` Jeff King
2014-04-23 21:05                     ` Junio C Hamano [this message]
2014-04-24 12:20                       ` Stepan Kasal
2014-04-24 12:24                         ` [PATCH v3] git tag --contains: " Stepan Kasal
2014-04-25  5:54                           ` Jeff King
2014-09-20 18:18                           ` Andreas Schwab
2014-09-23 16:05                             ` Jeff King
2014-09-23 21:48                               ` Andreas Schwab
2014-09-23 22:41                                 ` Junio C Hamano
2014-04-23 19:59               ` [PATCH v2] git tag --contains : " Stepan Kasal
2014-04-23 19:17             ` Jeff King
2014-04-23 21:14               ` Johannes Schindelin

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=xmqqfvl3ycwk.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jeanjacques.lafay@gmail.com \
    --cc=kasal@ucw.cz \
    --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.