git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Heiko Voigt <hvoigt@hvoigt.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] help: correct behavior for is_executable on Windows
Date: Wed, 15 Aug 2012 16:15:08 -0700	[thread overview]
Message-ID: <7va9xv4uir.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20120815222911.GA44080@book.hvoigt.net> (Heiko Voigt's message of "Thu, 16 Aug 2012 00:29:13 +0200")

Heiko Voigt <hvoigt@hvoigt.net> writes:

> I do not know why you are against filling that information into "struct
> stat".

Because it is *WRONG*.  Isn't it a good enough reason?

If the issue you are trying to solve were """stat emulation on
Windows and Cygwin does not give the correct x-bit (and the user
sometimes has to work it around with "update-index --chmod"), and by
using other clues the emulation can be improved to give a better
result""", I agree that it would be a good solution to have the
"""Does it exist as a regular file and ends with ".exe"?  Otherwise
does it start with "MZ" or "#!"?""" heuristics in a helper function
correct_executable_stat(), and to have the implementation of stat
emulation on these two platforms call that shared helper function.

But look at the caller again.  The problem the caller wants this
function to solve is not "I want you to stat this file."  It has a
pathname, and only wants to know if it is an executable file.  It
does not care about who owns it, what time it was last touched,
etc., but calling the incomplete stat emulation on Windows will try
to come up with an answer, and the is_executable() function discards
most of it.  

In other words, you are solving a wrong problem with that approach.

"Run stat() and look at S_IXUSR" happens to be an implementation
detail that is valid only on POSIX systems for a function to answer
the question: "Is this an executable file?", and in that specific
implementation, the answer to that question appears in the S_IXUSR
bit of st.st_mode.  That does not mean the "struct stat" is the best
container for the answer to that question on other platforms.  So
why structure your abstraction around the inappropriate data
structure?  Between the function (is_executable) and its callers,
there is only one bit that needs to be passed.

My preference is to remove "static int is_executable()" function
from help.c, have an "extern int is_executable(const char *)" that
has platform-specific implementation in compat/ layer, and call it
from help.c::list_commands_in_dir() without any #ifdef.  In
git-compat-util.h, have something like:

	#ifdef __CYGWIN__
	#define is_executable(path) cygwin_is_executable(path)
	#else
        # ifdef WIN32
        # define is_executable(path) win32_is_executable(path)
	# endif
	#endif

        #ifndef is_exectutable
	#define is_executable(path) posix_is_executable(path)
	#endif

        extern int is_executable(const char *);

I wouldn't mind seeing the implementation of posix_is_executable()
in help.c, which will be dead-code on Windows and Cygwin, if that
makes linking and Makefile easier.

  reply	other threads:[~2012-08-15 23:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-11  7:00 [PATCH] help: correct behavior for is_executable on Windows Heiko Voigt
2012-08-12  4:30 ` Junio C Hamano
2012-08-13 17:02   ` Heiko Voigt
2012-08-13 17:48     ` Junio C Hamano
2012-08-15 16:50       ` Heiko Voigt
2012-08-15 17:53         ` Junio C Hamano
2012-08-15 19:39           ` Junio C Hamano
2012-08-15 22:29           ` Heiko Voigt
2012-08-15 23:15             ` Junio C Hamano [this message]
2012-08-16  2:02               ` Junio C Hamano
2012-08-16 16:35                 ` Heiko Voigt
  -- strict thread matches above, loose matches on Subject: below --
2017-01-27 13:50 Johannes Schindelin
2017-01-27 18:43 ` Junio C Hamano
2017-01-30 12:44   ` Johannes Schindelin

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=7va9xv4uir.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hvoigt@hvoigt.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).