All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Rast <trast@inf.ethz.ch>
To: Junio C Hamano <gitster@pobox.com>
Cc: <git@vger.kernel.org>, "Dale R. Worley" <worley@alum.mit.edu>
Subject: Re: [PATCH 0/2] open() error checking
Date: Tue, 16 Jul 2013 11:25:34 +0200	[thread overview]
Message-ID: <87hafukga9.fsf@linux-k42r.v.cablecom.net> (raw)
In-Reply-To: <7vtxjzlmaf.fsf@alter.siamese.dyndns.org> (Junio C. Hamano's message of "Fri, 12 Jul 2013 10:29:12 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> Thomas Rast <trast@inf.ethz.ch> writes:
>
>> I originally had a four-patch series to open 0/1/2 from /dev/null, but
>> then I noticed that this was shot down in 2008:
>>
>>   http://thread.gmane.org/gmane.comp.version-control.git/93605/focus=93896
>
> The way I recall the thread was not "shot down" but more like
> "fizzled out without seeing a clear consensus".  As a normal POSIX
> program, we do rely on fd#2 connected to an error stream, and I do
> agree with the general sentiment of that old thread that it is very
> wrong for warning() or die() to write to a pipe or file descriptor
> we opened for some other purpose, corrupting the destination.
>
> I briefly wondered if we can do the sanity check lazily (e.g. upon
> first warning() see of fd#2 is open and otherwise die silently), but
> we may open a fd (e.g. to create a new loose object) that may happen
> to grab fd#2 and then it is too late for us to do anything about it,
> so...

I think we'd have to do it on startup.  Since we do many things already,
a few extra dup calls should hardly matter.

I'll send the patches in reply in a minute, I had them lying around
already.  But if you (again) decide that it's not worth it, I don't care
too deeply.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

  reply	other threads:[~2013-07-16  9:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-12  8:58 [PATCH 0/2] open() error checking Thomas Rast
2013-07-12  8:58 ` [PATCH 1/2] git_mkstemps: correctly test return value of open() Thomas Rast
2013-07-16  9:37   ` Thomas Rast
2013-07-17 19:29     ` Junio C Hamano
2013-07-18 12:32       ` Drew Northup
2013-07-18 17:46         ` Junio C Hamano
2013-07-18 17:47           ` Junio C Hamano
2013-07-18 20:32           ` Dale R. Worley
2013-07-18 20:49             ` Eric Sunshine
2013-07-18 20:54             ` Junio C Hamano
2013-07-18 22:46               ` Dale R. Worley
2013-07-18 23:23                 ` Junio C Hamano
2013-07-18 23:29                   ` Dale R. Worley
2013-07-12  8:58 ` [PATCH 2/2] run-command: dup_devnull(): guard against syscalls failing Thomas Rast
2013-07-12 17:29 ` [PATCH 0/2] open() error checking Junio C Hamano
2013-07-16  9:25   ` Thomas Rast [this message]
2013-07-16  9:27   ` [PATCH 1/2] daemon/shell: refactor redirection of 0/1/2 from /dev/null Thomas Rast
2013-07-16  9:27     ` [PATCH 2/2] git: ensure 0/1/2 are open in main() Thomas Rast

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=87hafukga9.fsf@linux-k42r.v.cablecom.net \
    --to=trast@inf.ethz.ch \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=worley@alum.mit.edu \
    /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.