Re: [PATCH v2 2/4] use strbuf_getcwd() to get the current working directory without fixed-sized buffers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 21.07.2014 04:33, schrieb Jeff King:
On Sun, Jul 20, 2014 at 06:49:54PM +0200, René Scharfe wrote:

diff --git a/builtin/init-db.c b/builtin/init-db.c
index 56f85e2..c4958b6 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -535,10 +535,10 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
  		usage(init_db_usage[0]);
  	}
  	if (is_bare_repository_cfg == 1) {
-		static char git_dir[PATH_MAX+1];
-
-		setenv(GIT_DIR_ENVIRONMENT,
-			getcwd(git_dir, sizeof(git_dir)), argc > 0);
+		struct strbuf cwd = STRBUF_INIT;
+		strbuf_getcwd(&cwd);
+		setenv(GIT_DIR_ENVIRONMENT, cwd.buf, argc > 0);
+		strbuf_release(&cwd);

Hmm. You are not making anything worse here, as we already do not check
the return value of getcwd. But what happens if it fails? Looks like we
currently get a segfault, and the new code will silently set the
variable to the empty string. Neither is particularly helpful.

Should we be using the xgetcwd helper that you add in the next patch?

Probably. And I was so glad to have found an example case for getcwd without dying and without touching the get-there-and-back cases. :) Guess I'll have to look closer at setup.c and perhaps unix-socket.c for a replacement.

By the way: Simply setting $GIT_DIR to "." probably won't work in the two cases, I guess?


-			setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir, sizeof(git_dir)), 0);
+			strbuf_getcwd(&cwd);
+			setenv(GIT_DIR_ENVIRONMENT, cwd.buf, 0);
+			strbuf_release(&cwd);

Ditto here.

-Peff

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]