git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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


      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).