Git Mailing List Archive on lore.kernel.org
 help / color / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Johannes Sixt <j6t@kdbg.org>,
	Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v2 0/2] Brown-bag fix on top of js/mingw-inherit-only-std-handles
Date: Sun, 01 Dec 2019 22:07:28 -0800
Message-ID: <xmqqk17fz2e7.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.1912011042460.31080@tvgsbejvaqbjf.bet> (Johannes Schindelin's message of "Sun, 1 Dec 2019 10:53:25 +0100 (CET)")

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> But the intention is not to help correct callers! The purpose of mapping
> `ERROR_SUCCESS` to 0 will help _only_ callers that try to report an error
> when none happened. On Windows, which is the only platform where the
> discussed function is compiled and used, `strerror(0)` has the
> well-established behavior of returning "No error".

But is the caller that ends up saying "No error" you mention below
by calling strerror() exists *only* on Windows port somewhere in
compat/ directory?  If the call to strerror() is made from a
codepath that is common to all platforms, then that caller *is*
wrong to do so after seeing *no* errors.

So, no, sorry, but I do not understand the above line of reasoning.

> Now imagine that a user encounters a bug where a code path does indeed
> incorrectly report an error where no error occurred (or where Git is
> looking for the error too late or something like that). You probably agree
> with me that we should really avoid reporting "Function not implemented"
> in such a case and rather say "No error", which will help figure out the
> bug much quicker.

Not really.  A BUG() that catches a call to this function that
should not be called when there is no error would help identify the
problematic caller a lot faster by being louder---those users who
get hit will raise their hands more readily than those who see "No
error" and wonders "why does Git give that error message when there
is no error?".  IOW, "No error" sounds like sweeping the issue under
the rug.

The argument could be "I do not want to be pressured to hunt for the
problematic caller, and taking the approach to be less loud than the
BUG() approach would allow the end users keep operating as if
nothing bad happened, so that I can hunt for the caller iff/when I
feel like it, and with no urgent need I can just ignore the hunt
altogether.  Not hitting with BUG() is a service to the end users
who shouldn't be made a guinea pig---that is why we want to sweep
the problematic caller under the rug.  It may delay the discovery
and fixing of problematic callers, which is a downside, though."

I would understand such an argument, even if I might not think that
such an argument makes the right tradeoff between not hitting the
users with BUG() and not being effective in finding the problematic
caller.

Thanks.

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29 21:44 [PATCH 0/1] " Johannes Schindelin via GitGitGadget
2019-11-29 21:44 ` [PATCH 1/1] mingw: do set `errno` correctly when trying to restrict handle inheritance Johannes Schindelin via GitGitGadget
2019-11-29 23:02   ` Johannes Sixt
2019-11-30 22:06     ` Johannes Schindelin
2019-11-30 22:16       ` Johannes Sixt
2019-11-30 10:36 ` [PATCH v2 0/2] Brown-bag fix on top of js/mingw-inherit-only-std-handles Johannes Schindelin via GitGitGadget
2019-11-30 10:36   ` [PATCH v2 1/2] mingw: do set `errno` correctly when trying to restrict handle inheritance Johannes Schindelin via GitGitGadget
2019-11-30 10:36   ` [PATCH v2 2/2] mingw: translate ERROR_SUCCESS to errno = 0 Johannes Schindelin via GitGitGadget
2019-11-30 18:04   ` [PATCH v2 0/2] Brown-bag fix on top of js/mingw-inherit-only-std-handles Junio C Hamano
2019-11-30 19:13     ` Johannes Sixt
2019-11-30 20:11       ` Andreas Schwab
2019-11-30 20:23         ` Junio C Hamano
2019-11-30 20:43           ` Andreas Schwab
2019-11-30 21:22             ` Johannes Schindelin
2019-11-30 20:21       ` Junio C Hamano
2019-12-01  6:26         ` Junio C Hamano
2019-12-01  9:53           ` Johannes Schindelin
2019-12-02  6:07             ` Junio C Hamano [this message]
2019-12-02  9:05               ` Johannes Schindelin
2019-11-30 19:20   ` Johannes Sixt
2019-11-30 22:09     ` Junio C Hamano
2019-12-02 11:33   ` [PATCH v3 " Johannes Schindelin via GitGitGadget
2019-12-02 11:33     ` [PATCH v3 1/2] mingw: do set `errno` correctly when trying to restrict handle inheritance Johannes Schindelin via GitGitGadget
2019-12-02 11:33     ` [PATCH v3 2/2] mingw: translate ERROR_SUCCESS to errno = 0 Johannes Schindelin via GitGitGadget
2019-12-02 17:35     ` [PATCH v3 0/2] Brown-bag fix on top of js/mingw-inherit-only-std-handles Johannes Sixt
2019-12-02 19:04       ` Junio C Hamano
2019-12-03 12:04       ` Johannes Schindelin

Reply instructions:

You may reply publically 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=xmqqk17fz2e7.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=j6t@kdbg.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

Git Mailing List Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/git/0 git/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 git git/ https://lore.kernel.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.git


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git