From: Junio C Hamano <email@example.com> To: Johannes Schindelin <Johannes.Schindelin@gmx.de> Cc: Johannes Sixt <firstname.lastname@example.org>, Johannes Schindelin via GitGitGadget <email@example.com>, firstname.lastname@example.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: <email@example.com> (raw) In-Reply-To: <nycvar.QRO.firstname.lastname@example.org> (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.
next prev parent 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 \ --email@example.com \ --firstname.lastname@example.org \ --cc=Johannes.Schindelin@gmx.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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 \ firstname.lastname@example.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