From: "Randall S. Becker" <rsbecker@nexbridge.com>
To: "'Brandon Casey'" <drafnel@gmail.com>,
"'Junio C Hamano'" <gitster@pobox.com>
Cc: "'git'" <git@vger.kernel.org>,
"'Kyle Evans'" <kevans@freebsd.org>,
"'Jeff King'" <peff@peff.net>
Subject: RE: fread reading directories
Date: Mon, 8 Jun 2020 15:41:10 -0400 [thread overview]
Message-ID: <013101d63dcc$c5fc5740$51f505c0$@nexbridge.com> (raw)
In-Reply-To: <CA+sFfMcQ+HQPk3SMsBhWjfLiVLzfhHSv9OpzPHAJt5b50TEPeQ@mail.gmail.com>
On June 8, 2020 3:08 PM, Brandon Casey wrote:
> To: Junio C Hamano <gitster@pobox.com>
> Cc: git <git@vger.kernel.org>; Kyle Evans <kevans@freebsd.org>; Jeff King
> <peff@peff.net>
> Subject: Re: fread reading directories
>
> On Mon, Jun 8, 2020 at 10:18 AM Junio C Hamano <gitster@pobox.com>
> wrote:
> >
> > It may make sense to do one of the two things:
> >
> > - The lighter weight one is to rename the macro to the reflect the
> > trait we are trying to capture more faithfully: "fopen opens
> > directories" and leave the code and performance characteristics
> > as-is.
> >
> > - Heavier weight one is to audit callers of fopen() and only let
> > those that know they do not have a directory directly call
> > fopen(). The other callers would call our wrapper under a
> > different name. This way, the former won't have to pay the
> > overhead of checking for "you gave me a directory but I only take
> > a file" error twice. This is what Brandon proposed in the
> > thread.
> >
> > Doing neither would leave this seed of confusion for later readers,
> > which is not ideal. I am tempted to say that we for now should do an
> > even lighter variant of the former, which is to give a comment.
> >
> > Thoughts?
>
> I'd suggest a medium weight approach which would be to introduce a new
> function with an appropriate name (fopen_file_only()?) that behaves the way
> we want it to, and replace every existing fopen() call with this new function.
> We could introduce a new macro, which I think would only be used on
> Windows, to say "fopen already fails to open directories"
> (FOPEN_FAILS_ON_DIRECTORIES?) so that fopen_file_only could be
> simplified to just a bare fopen there. That way it's clear to the reader, at the
> callsite, that the call does not have the standard behavior of fopen.
>
> Then, FREAD_READS_DIRECTORIES could be removed from all but the 1 or 2
> platforms that it was originally set for. I'd imagine that we'd basically just
> promote the git_fopen() function from compat to become the
> implementation of the first tier fopen_file_only() function. On the
> FREAD_READS_DIRECTORIES platforms, a bare fopen would also become
> fopen_file_only(). The call to fopen() within fopen_file_only() would
> obviously need to take this into account to ensure that it calls the real
> fopen().
>
> I think this would put the pieces in place for someone to audit all of the
> existing uses of fopen_file_only() and potentially replace them with a straight
> fopen() if appropriate. And it would allow future code to explicitly make the
> choice between fopen_file_only() or just fopen().
>
> None of this would produce any functional change on any of our platforms,
> but I think it would make things more clear.
Please keep me on the loop on this one. The NonStop platforms have FREAD_READS_DIRECTORIES UnfortunatelyYes. We will want to move to the new structure as soon as we can, so compat makes me comfortable.
Thanks,
Randall
prev parent reply other threads:[~2020-06-08 19:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-06 22:36 fread reading directories Kyle Evans
2020-06-07 17:05 ` Junio C Hamano
2020-06-07 17:16 ` Kyle Evans
2020-06-08 17:18 ` Junio C Hamano
2020-06-08 19:08 ` Brandon Casey
2020-06-08 19:41 ` Randall S. Becker [this message]
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='013101d63dcc$c5fc5740$51f505c0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=drafnel@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kevans@freebsd.org \
--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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).