* [PATCH 11/17] Add platform files for MSVC porting
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
Add msvc.c and msvc.h to build git under MSVC
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/msvc.c | 35 +++++++++++++++++++++++++++++++++
compat/msvc.h | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++
git-compat-util.h | 3 ++
3 files changed, 93 insertions(+), 0 deletions(-)
create mode 100644 compat/msvc.c
create mode 100644 compat/msvc.h
diff --git a/compat/msvc.c b/compat/msvc.c
new file mode 100644
index 0000000..ac04a4c
--- /dev/null
+++ b/compat/msvc.c
@@ -0,0 +1,35 @@
+#include "../git-compat-util.h"
+#include "win32.h"
+#include <conio.h>
+#include "../strbuf.h"
+
+DIR *opendir(const char *name)
+{
+ int len;
+ DIR *p;
+ p = (DIR*)malloc(sizeof(DIR));
+ memset(p, 0, sizeof(DIR));
+ strncpy(p->dd_name, name, PATH_MAX);
+ len = strlen(p->dd_name);
+ p->dd_name[len] = '/';
+ p->dd_name[len+1] = '*';
+
+ if (p == NULL)
+ return NULL;
+
+ p->dd_handle = _findfirst(p->dd_name, &p->dd_dta);
+
+ if (p->dd_handle == -1) {
+ free(p);
+ return NULL;
+ }
+ return p;
+}
+int closedir(DIR *dir)
+{
+ _findclose(dir->dd_handle);
+ free(dir);
+ return 0;
+}
+
+#include "mingw.c"
diff --git a/compat/msvc.h b/compat/msvc.h
new file mode 100644
index 0000000..6daf313
--- /dev/null
+++ b/compat/msvc.h
@@ -0,0 +1,55 @@
+#ifndef __MSVC__HEAD
+#define __MSVC__HEAD
+
+/* Define minimize windows version */
+#define WINVER 0x0500
+#define _WIN32_WINNT 0x0500
+#define _WIN32_WINDOWS 0x0410
+#define _WIN32_IE 0x0700
+#define NTDDI_VERSION NTDDI_WIN2KSP1
+#include <winsock2.h>
+#include <direct.h>
+#include <process.h>
+#include <malloc.h>
+
+/* porting function */
+#define inline __inline
+#define __inline__ __inline
+#define __attribute__(x)
+#define va_copy(dst, src) ((dst) = (src))
+
+static __inline int strcasecmp (const char *s1, const char *s2)
+{
+ int size1 = strlen(s1);
+ int sisz2 = strlen(s2);
+ return _strnicmp(s1, s2, sisz2 > size1 ? sisz2 : size1);
+}
+
+#undef ERROR
+#undef stat
+#undef _stati64
+#include "compat/mingw.h"
+#undef stat
+#define stat _stati64
+#define _stat64(x,y) mingw_lstat(x,y)
+
+/*
+ Even though _stati64 is normally just defined at _stat64
+ on Windows, we specify it here as a proper struct to avoid
+ compiler warnings about macro redefinition due to magic in
+ mingw.h. Struct taken from ReactOS (GNU GPL license).
+*/
+struct _stati64 {
+ _dev_t st_dev;
+ _ino_t st_ino;
+ unsigned short st_mode;
+ short st_nlink;
+ short st_uid;
+ short st_gid;
+ _dev_t st_rdev;
+ __int64 st_size;
+ time_t st_atime;
+ time_t st_mtime;
+ time_t st_ctime;
+};
+#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index e5e9f39..8ea444f 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -113,6 +113,9 @@
/* pull in Windows compatibility stuff */
#include "compat/mingw.h"
#endif /* __MINGW32__ */
+#ifdef _MSC_VER
+#include "compat/msvc.h"
+#endif
#ifndef NO_LIBGEN_H
#include <libgen.h>
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 09/17] Add empty header files for MSVC port
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
MSVC lacks many of the header files included by git-compat-util.h,
so add blank header files for these instead of going ifdef crazy.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/vcbuild/include/arpa/inet.h | 1 +
compat/vcbuild/include/grp.h | 1 +
compat/vcbuild/include/inttypes.h | 1 +
compat/vcbuild/include/netdb.h | 1 +
compat/vcbuild/include/netinet/in.h | 1 +
compat/vcbuild/include/netinet/tcp.h | 1 +
compat/vcbuild/include/pwd.h | 1 +
compat/vcbuild/include/sys/ioctl.h | 1 +
compat/vcbuild/include/sys/param.h | 1 +
compat/vcbuild/include/sys/poll.h | 1 +
compat/vcbuild/include/sys/select.h | 1 +
compat/vcbuild/include/sys/socket.h | 1 +
compat/vcbuild/include/sys/time.h | 1 +
compat/vcbuild/include/sys/wait.h | 1 +
14 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 compat/vcbuild/include/arpa/inet.h
create mode 100644 compat/vcbuild/include/grp.h
create mode 100644 compat/vcbuild/include/inttypes.h
create mode 100644 compat/vcbuild/include/netdb.h
create mode 100644 compat/vcbuild/include/netinet/in.h
create mode 100644 compat/vcbuild/include/netinet/tcp.h
create mode 100644 compat/vcbuild/include/pwd.h
create mode 100644 compat/vcbuild/include/sys/ioctl.h
create mode 100644 compat/vcbuild/include/sys/param.h
create mode 100644 compat/vcbuild/include/sys/poll.h
create mode 100644 compat/vcbuild/include/sys/select.h
create mode 100644 compat/vcbuild/include/sys/socket.h
create mode 100644 compat/vcbuild/include/sys/time.h
create mode 100644 compat/vcbuild/include/sys/wait.h
diff --git a/compat/vcbuild/include/arpa/inet.h b/compat/vcbuild/include/arpa/inet.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/arpa/inet.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/grp.h b/compat/vcbuild/include/grp.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/grp.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/inttypes.h b/compat/vcbuild/include/inttypes.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/inttypes.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netdb.h b/compat/vcbuild/include/netdb.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/netdb.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netinet/in.h b/compat/vcbuild/include/netinet/in.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/netinet/in.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/netinet/tcp.h b/compat/vcbuild/include/netinet/tcp.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/netinet/tcp.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/pwd.h b/compat/vcbuild/include/pwd.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/pwd.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/ioctl.h b/compat/vcbuild/include/sys/ioctl.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/sys/ioctl.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/param.h b/compat/vcbuild/include/sys/param.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/sys/param.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/poll.h b/compat/vcbuild/include/sys/poll.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/sys/poll.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/select.h b/compat/vcbuild/include/sys/select.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/sys/select.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/socket.h b/compat/vcbuild/include/sys/socket.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/sys/socket.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/time.h b/compat/vcbuild/include/sys/time.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/sys/time.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
diff --git a/compat/vcbuild/include/sys/wait.h b/compat/vcbuild/include/sys/wait.h
new file mode 100644
index 0000000..0d8552a
--- /dev/null
+++ b/compat/vcbuild/include/sys/wait.h
@@ -0,0 +1 @@
+/* Intentionally empty file to support building git with MSVC */
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 08/17] Test for WIN32 instead of __MINGW32_
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
The code which is conditional on MinGW32 is actually conditional on Windows.
Use the WIN32 symbol, which is defined by the MINGW32 and MSVC environments,
but not by Cygwin.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
help.c | 2 +-
| 4 ++--
run-command.c | 8 ++++----
run-command.h | 2 +-
setup.c | 2 +-
5 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/help.c b/help.c
index fd51b8e..e8db31f 100644
--- a/help.c
+++ b/help.c
@@ -126,7 +126,7 @@ static int is_executable(const char *name)
!S_ISREG(st.st_mode))
return 0;
-#ifdef __MINGW32__
+#ifdef WIN32
{ /* cannot trust the executable bit, peek into the file instead */
char buf[3] = { 0 };
int n;
--git a/pager.c b/pager.c
index f416d38..86facec 100644
--- a/pager.c
+++ b/pager.c
@@ -9,7 +9,7 @@
static int spawned_pager;
-#ifndef __MINGW32__
+#ifndef WIN32
static void pager_preexec(void)
{
/*
@@ -72,7 +72,7 @@ void setup_pager(void)
static const char *env[] = { "LESS=FRSX", NULL };
pager_process.env = env;
}
-#ifndef __MINGW32__
+#ifndef WIN32
pager_process.preexec_cb = pager_preexec;
#endif
if (start_command(&pager_process))
diff --git a/run-command.c b/run-command.c
index 91f6d2e..cb006e7 100644
--- a/run-command.c
+++ b/run-command.c
@@ -75,7 +75,7 @@ fail_pipe:
trace_argv_printf(cmd->argv, "trace: run_command:");
-#ifndef __MINGW32__
+#ifndef WIN32
fflush(NULL);
cmd->pid = fork();
if (!cmd->pid) {
@@ -315,7 +315,7 @@ int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const
return run_command(&cmd);
}
-#ifdef __MINGW32__
+#ifdef WIN32
static unsigned WINAPI run_thread(void *data)
{
struct async *async = data;
@@ -331,7 +331,7 @@ int start_async(struct async *async)
return error("cannot create pipe: %s", strerror(errno));
async->out = pipe_out[0];
-#ifndef __MINGW32__
+#ifndef WIN32
/* Flush stdio before fork() to avoid cloning buffers */
fflush(NULL);
@@ -360,7 +360,7 @@ int start_async(struct async *async)
int finish_async(struct async *async)
{
-#ifndef __MINGW32__
+#ifndef WIN32
int ret = wait_or_whine(async->pid, "child process", 0);
#else
DWORD ret = 0;
diff --git a/run-command.h b/run-command.h
index 0c00b25..fb34209 100644
--- a/run-command.h
+++ b/run-command.h
@@ -70,7 +70,7 @@ struct async {
int (*proc)(int fd, void *data);
void *data;
int out; /* caller reads from here and closes it */
-#ifndef __MINGW32__
+#ifndef WIN32
pid_t pid;
#else
HANDLE tid;
diff --git a/setup.c b/setup.c
index e3781b6..029371e 100644
--- a/setup.c
+++ b/setup.c
@@ -41,7 +41,7 @@ const char *prefix_path(const char *prefix, int len, const char *path)
const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
{
static char path[PATH_MAX];
-#ifndef __MINGW32__
+#ifndef WIN32
if (!pfx || !*pfx || is_absolute_path(arg))
return arg;
memcpy(path, pfx, pfx_len);
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 06/17] mingw.c: Use the O_BINARY flag to open files
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
On Windows, binary files must be opened using the O_BINARY flag for
untranslated mode. MinGW does this for us automatically, but Microsoft
Visual C++ does not.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/mingw.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 5478b74..12db9a6 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -132,7 +132,7 @@ int mingw_open (const char *filename, int oflags, ...)
if (!strcmp(filename, "/dev/null"))
filename = "nul";
- fd = open(filename, oflags, mode);
+ fd = open(filename, oflags | O_BINARY, mode);
if (fd < 0 && (oflags & O_CREAT) && errno == EACCES) {
DWORD attrs = GetFileAttributes(filename);
@@ -278,7 +278,7 @@ int mkstemp(char *template)
char *filename = mktemp(template);
if (filename == NULL)
return -1;
- return open(filename, O_RDWR | O_CREAT, 0600);
+ return open(filename, O_RDWR | O_CREAT | O_BINARY, 0600);
}
int gettimeofday(struct timeval *tv, void *tz)
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 07/17] Fix __stdcall/WINAPI placement and function prototype
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
WINAPI is a macro which translates into the proper calling convention, so
replace __stdcall with that.
MSVC requires WINAPI to be between the functions return value and the
function name, and that the function pointer type is in the form of
return_type (WINAPI *function_name)(arguments...)
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/mingw.c | 4 ++--
run-command.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 12db9a6..90764eb 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1029,7 +1029,7 @@ static sig_handler_t timer_fn = SIG_DFL;
* length to call the signal handler.
*/
-static __stdcall unsigned ticktack(void *dummy)
+static unsigned WINAPI ticktack(void *dummy)
{
while (WaitForSingleObject(timer_event, timer_interval) == WAIT_TIMEOUT) {
if (timer_fn == SIG_DFL)
@@ -1156,7 +1156,7 @@ void mingw_open_html(const char *unixpath)
int link(const char *oldpath, const char *newpath)
{
- typedef BOOL WINAPI (*T)(const char*, const char*, LPSECURITY_ATTRIBUTES);
+ typedef BOOL (WINAPI *T)(const char*, const char*, LPSECURITY_ATTRIBUTES);
static T create_hard_link = NULL;
if (!create_hard_link) {
create_hard_link = (T) GetProcAddress(
diff --git a/run-command.c b/run-command.c
index 02aaedf..91f6d2e 100644
--- a/run-command.c
+++ b/run-command.c
@@ -316,7 +316,7 @@ int run_command_v_opt_cd_env(const char **argv, int opt, const char *dir, const
}
#ifdef __MINGW32__
-static __stdcall unsigned run_thread(void *data)
+static unsigned WINAPI run_thread(void *data)
{
struct async *async = data;
return async->proc(async->fd_for_proc, async->data);
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 05/17] Change regerror() declaration from K&R style to ANSI C (C89)
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
The MSVC headers typedef errcode as int, and thus confused the
compiler in the K&R style definition. ANSI style deconfuses it.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/regex/regex.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/compat/regex/regex.c b/compat/regex/regex.c
index 5ea0075..67d5c37 100644
--- a/compat/regex/regex.c
+++ b/compat/regex/regex.c
@@ -4852,11 +4852,8 @@ regexec (preg, string, nmatch, pmatch, eflags)
from either regcomp or regexec. We don't use PREG here. */
size_t
-regerror (errcode, preg, errbuf, errbuf_size)
- int errcode;
- const regex_t *preg;
- char *errbuf;
- size_t errbuf_size;
+regerror(int errcode, const regex_t *preg,
+ char *errbuf, size_t errbuf_size)
{
const char *msg;
size_t msg_size;
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 04/17] Add define guards to compat/win32.h
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/win32.h | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/compat/win32.h b/compat/win32.h
index c26384e..e8c178d 100644
--- a/compat/win32.h
+++ b/compat/win32.h
@@ -1,3 +1,6 @@
+#ifndef WIN32_H
+#define WIN32_H
+
/* common Win32 functions for MinGW and Cygwin */
#include <windows.h>
@@ -32,3 +35,5 @@ static inline int get_file_attr(const char *fname, WIN32_FILE_ATTRIBUTE_DATA *fd
return ENOENT;
}
}
+
+#endif
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 02/17] boolean is a typedef under MSVC, so rename variable to 'i_boolean'
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
With MSVC 'boolean' is already a typedef to unsigned char in
the rpcndr.h in the SDK. So, just rename to 'i_boolean' to avoid
conflicts in this one file, instead of any include magic.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
test-parse-options.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/test-parse-options.c b/test-parse-options.c
index efa734b..0c2d327 100644
--- a/test-parse-options.c
+++ b/test-parse-options.c
@@ -1,7 +1,7 @@
#include "cache.h"
#include "parse-options.h"
-static int boolean = 0;
+static int i_boolean = 0;
static int integer = 0;
static unsigned long timestamp;
static int abbrev = 7;
@@ -34,10 +34,10 @@ int main(int argc, const char **argv)
NULL
};
struct option options[] = {
- OPT_BOOLEAN('b', "boolean", &boolean, "get a boolean"),
- OPT_BIT('4', "or4", &boolean,
+ OPT_BOOLEAN('b', "boolean", &i_boolean, "get a boolean"),
+ OPT_BIT('4', "or4", &i_boolean,
"bitwise-or boolean with ...0100", 4),
- OPT_NEGBIT(0, "neg-or4", &boolean, "same as --no-or4", 4),
+ OPT_NEGBIT(0, "neg-or4", &i_boolean, "same as --no-or4", 4),
OPT_GROUP(""),
OPT_INTEGER('i', "integer", &integer, "get a integer"),
OPT_INTEGER('j', NULL, &integer, "get a integer, too"),
@@ -57,7 +57,7 @@ int main(int argc, const char **argv)
OPT_ARGUMENT("quux", "means --quux"),
OPT_NUMBER_CALLBACK(&integer, "set integer to NUM",
number_callback),
- { OPTION_BOOLEAN, '+', NULL, &boolean, NULL, "same as -b",
+ { OPTION_BOOLEAN, '+', NULL, &i_boolean, NULL, "same as -b",
PARSE_OPT_NOARG | PARSE_OPT_NONEG | PARSE_OPT_NODASH },
OPT_GROUP("Standard options"),
OPT__ABBREV(&abbrev),
@@ -70,7 +70,7 @@ int main(int argc, const char **argv)
argc = parse_options(argc, argv, prefix, options, usage, 0);
- printf("boolean: %d\n", boolean);
+ printf("boolean: %d\n", i_boolean);
printf("integer: %u\n", integer);
printf("timestamp: %lu\n", timestamp);
printf("string: %s\n", string ? string : "(not set)");
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 03/17] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
Microsoft's vsnprintf function does not add NUL at the end
of the buffer, if the result fits the buffer size exactly.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/snprintf.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/compat/snprintf.c b/compat/snprintf.c
index 4d07087..e1e0e75 100644
--- a/compat/snprintf.c
+++ b/compat/snprintf.c
@@ -2,12 +2,14 @@
/*
* The size parameter specifies the available space, i.e. includes
- * the trailing NUL byte; but Windows's vsnprintf expects the
- * number of characters to write, and does not necessarily write the
- * trailing NUL.
+ * the trailing NUL byte; but Windows's vsnprintf uses the entire
+ * buffer and avoids the trailing NUL, should the buffer be exactly
+ * big enough for the result. Defining SNPRINTF_SIZE_CORR to 1 will
+ * therefore remove 1 byte from the reported buffer size, so we
+ * always have room for a trailing NUL byte.
*/
#ifndef SNPRINTF_SIZE_CORR
-#if defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4
+#if defined(WIN32) && (!defined(__GNUC__) || __GNUC__ < 4)
#define SNPRINTF_SIZE_CORR 1
#else
#define SNPRINTF_SIZE_CORR 0
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [PATCH 01/17] Avoid declaration after statement
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
In-Reply-To: <cover.1252925290.git.mstormo@gmail.com>
From: Frank Li <lznuaa@gmail.com>
Microsoft Visual C++ does not understand this C99 style
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
---
compat/mingw.c | 14 ++++++++++----
help.c | 3 ++-
run-command.c | 2 ++
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 36ef8d3..5478b74 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -123,13 +123,17 @@ int mingw_open (const char *filename, int oflags, ...)
{
va_list args;
unsigned mode;
+ int fd;
+
va_start(args, oflags);
mode = va_arg(args, int);
va_end(args);
if (!strcmp(filename, "/dev/null"))
filename = "nul";
- int fd = open(filename, oflags, mode);
+
+ fd = open(filename, oflags, mode);
+
if (fd < 0 && (oflags & O_CREAT) && errno == EACCES) {
DWORD attrs = GetFileAttributes(filename);
if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY))
@@ -580,10 +584,11 @@ static char **get_path_split(void)
static void free_path_split(char **path)
{
+ char **p = path;
+
if (!path)
return;
- char **p = path;
while (*p)
free(*p++);
free(path);
@@ -1120,9 +1125,9 @@ int sigaction(int sig, struct sigaction *in, struct sigaction *out)
#undef signal
sig_handler_t mingw_signal(int sig, sig_handler_t handler)
{
+ sig_handler_t old = timer_fn;
if (sig != SIGALRM)
return signal(sig, handler);
- sig_handler_t old = timer_fn;
timer_fn = handler;
return old;
}
@@ -1209,8 +1214,9 @@ struct dirent *mingw_readdir(DIR *dir)
if (dir->dd_handle == (long)INVALID_HANDLE_VALUE && dir->dd_stat == 0)
{
+ DWORD lasterr;
handle = FindFirstFileA(dir->dd_name, &buf);
- DWORD lasterr = GetLastError();
+ lasterr = GetLastError();
dir->dd_handle = (long)handle;
if (handle == INVALID_HANDLE_VALUE && (lasterr != ERROR_NO_MORE_FILES)) {
errno = err_win_to_posix(lasterr);
diff --git a/help.c b/help.c
index 294337e..fd51b8e 100644
--- a/help.c
+++ b/help.c
@@ -127,7 +127,7 @@ static int is_executable(const char *name)
return 0;
#ifdef __MINGW32__
- /* cannot trust the executable bit, peek into the file instead */
+{ /* cannot trust the executable bit, peek into the file instead */
char buf[3] = { 0 };
int n;
int fd = open(name, O_RDONLY);
@@ -140,6 +140,7 @@ static int is_executable(const char *name)
st.st_mode |= S_IXUSR;
close(fd);
}
+}
#endif
return st.st_mode & S_IXUSR;
}
diff --git a/run-command.c b/run-command.c
index ac314a5..02aaedf 100644
--- a/run-command.c
+++ b/run-command.c
@@ -134,6 +134,7 @@ fail_pipe:
error("cannot fork() for %s: %s", cmd->argv[0],
strerror(failed_errno = errno));
#else
+{
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
const char **sargv = cmd->argv;
char **env = environ;
@@ -197,6 +198,7 @@ fail_pipe:
dup2(s1, 1), close(s1);
if (s2 >= 0)
dup2(s2, 2), close(s2);
+}
#endif
if (cmd->pid < 0) {
--
1.6.2.1.418.g33d56.dirty
^ permalink raw reply related
* [RFC/PATCH v2 00/17] Build Git with MSVC
From: Marius Storm-Olsen @ 2009-09-14 13:11 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git, lznuaa, Marius Storm-Olsen
Here's a second roll of the series for supporting compilation of Git
using Visual C++ (MSVC). (Sorry for the long delay on a followup, time
is in short supply these days)
There's no guarantee that the compiled result will work as well as the
current MinGW compile, or at all. However, I think it's important to
get the Git repo to a compilable state with MSVC as quickly as
possible, to further enable contributions from the Windows developers
which we are sorely lacking at the moment.
I hope that a repo which compiles successfully with the tools they are
accustomed to (also a very good debugger) will entice them to send more
patches.
In addition to this series, I have also setup a repo with binaries of
the required libs to compile Git with MSVC. Only 32bit versions for now.
So, the developer can choose to either use that, or Frank's source code
repo to build Git with MSVC. You'll find the binary repo here:
http://repo.or.cz/w/msvcgit.git
Note that the binaries will still require the msysgit environment for
execution, due to the non-binary components of Git. (Scripts, gitk,
git-gui, etc). You'll find that repo here:
http://repo.or.cz/w/msysgit.git
=== V2 2009.09.14 ===
1) Rebased ontop on current git.git 'next'.
2) Fixed code and commit msgs based on the previous feedback.
Let me know if I forgot anything!
3) Added a proper Makefile patch for MSVC support.
You now compile with 'make MSVC=1'.
4) Added perl scripts (contrib) which uses GNU Make output to generate
MSVC IDE (.sln & .vcproj) projects and QMake projects, and picking
up the project settings from the Makefile, so it's all in one place.
5) Added necessary patches to make things compile ontop of current
'next'.
=== V1 2009.08.21 ===
So, Frank Li started this series, and I took it upon my self to help
out a bit; cleaning, reorganizing, rebasing the series. Hopefully
we're now a bit closer to including the series into mainline..
Here's a summary of what has happend:
1) This series is rebased ontop of git.git 'next', which needed an
extra patch to avoid a non-constant array creation, which
mscv doesn't like.
2) I've polished (tied to anyways) the commit messages a bit.
3) I've applied much of the feedback provided to the first round of
the patches.
4) I've split, merged and reordered some of the patches, so things
that belong together are in the same commits, and in a order of
'importance'
5) I've removed the
#define func _func
stuff, as it's not needed and Microsoft cannot really kill the
compatibility functions anyways. So, adding the define
_CRT_NONSTDC_NO_DEPRECATE
will kill the warnings seen without the defines above.
6) ..probably much more as well, but I forget..
Note: I did not sign off on the last two commits, which involve the
adding of the vcproj files, since I don't agree on adding them as is.
We need a Makefile way of compiling primarily, and second, a script
to generate the vcproj, as already discussed. But the commits are
included for completeness, at to let others compile and play with it.
I've kept the original author as is, and just signed the patches..
Thanks for watching, now bring on the comments!
Frank Li (8):
Avoid declaration after statement
Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
Change regerror() declaration from K&R style to ANSI C (C89)
mingw.c: Use the O_BINARY flag to open files
Fix __stdcall/WINAPI placement and function prototype
Test for WIN32 instead of __MINGW32_
Add MinGW header files to build git with MSVC
Add platform files for MSVC porting
Marius Storm-Olsen (9):
boolean is a typedef under MSVC, so rename variable to 'i_boolean'
Add define guards to compat/win32.h
Add empty header files for MSVC port
Make usage of windows.h lean and mean
Define strncasecmp as _strnicmp for MSVC
Add ftruncate implementation for MSVC
Add MSVC to Makefile
Add README for MSVC build
Add scripts to generate projects for other buildsystems (MSVC vcproj,
QMake)
.gitignore | 11 +
Makefile | 54 +++-
compat/mingw.c | 22 +-
compat/mingw.h | 2 +
compat/msvc.c | 43 ++
compat/msvc.h | 51 +++
compat/regex/regex.c | 7 +-
compat/snprintf.c | 10 +-
compat/vcbuild/README | 50 +++
compat/vcbuild/include/alloca.h | 1 +
compat/vcbuild/include/arpa/inet.h | 1 +
compat/vcbuild/include/dirent.h | 128 ++++++
compat/vcbuild/include/grp.h | 1 +
compat/vcbuild/include/inttypes.h | 1 +
compat/vcbuild/include/netdb.h | 1 +
compat/vcbuild/include/netinet/in.h | 1 +
compat/vcbuild/include/netinet/tcp.h | 1 +
compat/vcbuild/include/pwd.h | 1 +
compat/vcbuild/include/sys/ioctl.h | 1 +
compat/vcbuild/include/sys/param.h | 1 +
compat/vcbuild/include/sys/poll.h | 1 +
compat/vcbuild/include/sys/select.h | 1 +
compat/vcbuild/include/sys/socket.h | 1 +
compat/vcbuild/include/sys/time.h | 1 +
compat/vcbuild/include/sys/utime.h | 34 ++
compat/vcbuild/include/sys/wait.h | 1 +
compat/vcbuild/include/unistd.h | 92 ++++
compat/vcbuild/include/utime.h | 1 +
compat/vcbuild/scripts/clink.pl | 48 +++
compat/vcbuild/scripts/lib.pl | 26 ++
compat/win32.h | 7 +
compat/winansi.c | 1 -
contrib/buildsystems/Generators.pm | 42 ++
contrib/buildsystems/Generators/QMake.pm | 189 +++++++++
contrib/buildsystems/Generators/Vcproj.pm | 639 +++++++++++++++++++++++++++++
contrib/buildsystems/engine.pl | 353 ++++++++++++++++
contrib/buildsystems/generate | 29 ++
contrib/buildsystems/parse.pl | 228 ++++++++++
git-compat-util.h | 9 +
help.c | 5 +-
pager.c | 4 +-
run-command.c | 12 +-
run-command.h | 2 +-
setup.c | 2 +-
test-parse-options.c | 12 +-
thread-utils.c | 5 +-
46 files changed, 2094 insertions(+), 39 deletions(-)
create mode 100644 compat/msvc.c
create mode 100644 compat/msvc.h
create mode 100644 compat/vcbuild/README
create mode 100644 compat/vcbuild/include/alloca.h
create mode 100644 compat/vcbuild/include/arpa/inet.h
create mode 100644 compat/vcbuild/include/dirent.h
create mode 100644 compat/vcbuild/include/grp.h
create mode 100644 compat/vcbuild/include/inttypes.h
create mode 100644 compat/vcbuild/include/netdb.h
create mode 100644 compat/vcbuild/include/netinet/in.h
create mode 100644 compat/vcbuild/include/netinet/tcp.h
create mode 100644 compat/vcbuild/include/pwd.h
create mode 100644 compat/vcbuild/include/sys/ioctl.h
create mode 100644 compat/vcbuild/include/sys/param.h
create mode 100644 compat/vcbuild/include/sys/poll.h
create mode 100644 compat/vcbuild/include/sys/select.h
create mode 100644 compat/vcbuild/include/sys/socket.h
create mode 100644 compat/vcbuild/include/sys/time.h
create mode 100644 compat/vcbuild/include/sys/utime.h
create mode 100644 compat/vcbuild/include/sys/wait.h
create mode 100644 compat/vcbuild/include/unistd.h
create mode 100644 compat/vcbuild/include/utime.h
create mode 100644 compat/vcbuild/scripts/clink.pl
create mode 100644 compat/vcbuild/scripts/lib.pl
create mode 100644 contrib/buildsystems/Generators.pm
create mode 100644 contrib/buildsystems/Generators/QMake.pm
create mode 100644 contrib/buildsystems/Generators/Vcproj.pm
create mode 100644 contrib/buildsystems/engine.pl
create mode 100644 contrib/buildsystems/generate
create mode 100644 contrib/buildsystems/parse.pl
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Johannes Sixt @ 2009-09-14 13:09 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Jeff King, git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140532q693a7f9qc3d9b1d354cac356@mail.gmail.com>
Erik Faye-Lund schrieb:
> Compiling the following code gives a warning about unreachable code,
> so it's clear that msvc doesn't simply ignore the directive. I'm not
> saying that anyone suggested otherwise, I just wanted to know for
> sure.
>
> #include <stdio.h>
> #include <stdlib.h>
> void (*exit_fun)(int) = exit;
> void __declspec(noreturn) die(void);
> void die(void) { exit_fun(1); }
> int main(void) { printf("hello!\n"); die(); printf("world!\n"); }
In order to countermand any clever optimizations you should make it
-void (*exit_fun)(int) = exit;
+extern void (*exit_fun)(int);
(of course, this fails to link). But if this results in only *one* warning
(that the printf() call is unreachable), then I wouldn't bother with this
problem anymore, because you really should also have been warned that a
__declspec(noreturn) function actually does return.
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 12:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Erik Faye-Lund
In-Reply-To: <20090914124428.GA9394@coredump.intra.peff.net>
On Mon, Sep 14, 2009 at 2:44 PM, Jeff King <peff@peff.net> wrote:
> Right. What I'm guessing is that it sees the noreturn on die(), but then
> doesn't actually look inside die to confirm that the noreturn is upheld.
> You could test that with:
>
> #include <stdlib.h>
> void __declspec(noreturn) die(void);
> void die(void) { }
> int main(void) { die(); }
>
> If it doesn't complain, then I am right. If it does, then it is
> something magic with the function pointer (presumably it decides that
> the function pointer could exit, so it stops the analysis and gives your
> code the benefit of the doubt).
It seems that you are right. It doesn't complain here.
>> The arguments against each solution I see are these:
>> - abort() gives a run-time error instead of a compile-time warning, so
>> breakage is trickier to detect (on GCC, which seems to be the target
>> compiler for the vast majority of git-developers).
>> - NORETURN_PTR might be bit big of a hammer for a small problem, as it
>> "pollutes" the whole git source-tree instead of just usage.c.
>
> I don't know that NORETURN_PTR pollutes the whole source-tree. At least
> no more than NORETURN does. The only functions that will need it are
> these two function pointers.
Well, it does pollute the global name space, and it's "noise" when
reading the source code. But those are really very unimportant points
IMO.
And sure, that "pollution/noise" is there for the NORETURN case anyway
for a functional/practical reason, so you might argue that it
justifies the presence in the NORETURN_PTR case.
I'll wait a day or so and see if anyone else has any insight. If not,
I'll go ahead and re-post a version based on the
NORETURN_PTR-solution.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* codeBeamer, Collaborative ALM Solution for Git and Android
From: Intland Software @ 2009-09-14 12:49 UTC (permalink / raw)
To: git
Intland Software announces the availability of codeBeamer 5.4, the
award winning Collaborative Application Lifecycle Management Solution
for distributed software development. Today's challenge is to tackle
*Android sized projects* with 2GB of code and hundreds of thousands of
change sets, and codeBeamer 5.4 is capable of processing these
repositories.
Version highlights:
* Issue escalation with hierarchic working calendars
* Calculated tracker fields with rich formula
* Wiki page editing directly in Microsoft Word
* Scalable version control management
* Major enhancements in supporting Git and Mercurial
* Revised search: more relevancy, richer query syntax, friendlier interface
Links
* Product homepage: http://www.intland.com/products/cb/overview.html
* FREE download (no expiration!):
http://www.intland.com/products/download.html#download
* FREE hosted version: http://www.intland.com/products/download.html#trial
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Jeff King @ 2009-09-14 12:44 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140532q693a7f9qc3d9b1d354cac356@mail.gmail.com>
On Mon, Sep 14, 2009 at 02:32:38PM +0200, Erik Faye-Lund wrote:
> Compiling the following code gives a warning about unreachable code,
> so it's clear that msvc doesn't simply ignore the directive. I'm not
> saying that anyone suggested otherwise, I just wanted to know for
> sure.
>
> #include <stdio.h>
> #include <stdlib.h>
> void (*exit_fun)(int) = exit;
> void __declspec(noreturn) die(void);
> void die(void) { exit_fun(1); }
> int main(void) { printf("hello!\n"); die(); printf("world!\n"); }
Right. What I'm guessing is that it sees the noreturn on die(), but then
doesn't actually look inside die to confirm that the noreturn is upheld.
You could test that with:
#include <stdlib.h>
void __declspec(noreturn) die(void);
void die(void) { }
int main(void) { die(); }
If it doesn't complain, then I am right. If it does, then it is
something magic with the function pointer (presumably it decides that
the function pointer could exit, so it stops the analysis and gives your
code the benefit of the doubt).
> First of all, MSVC is not the only compiler that behaves this way. In
> fact, GCC the only compiler I've found that behaves this way (but I
> must admit, I only tested 4 different compilers, one of which (Comeau)
> does not support noreturn at all AFAICT). That behavior might be
> crappy, but it's not "MSVC's crappy noreturn handling" - it's
> "non-GCC's crappy noreturn handling" :P
Well, OK, I'll accept that. ;)
> The arguments against each solution I see are these:
> - abort() gives a run-time error instead of a compile-time warning, so
> breakage is trickier to detect (on GCC, which seems to be the target
> compiler for the vast majority of git-developers).
> - NORETURN_PTR might be bit big of a hammer for a small problem, as it
> "pollutes" the whole git source-tree instead of just usage.c.
I don't know that NORETURN_PTR pollutes the whole source-tree. At least
no more than NORETURN does. The only functions that will need it are
these two function pointers.
But I think your analysis is generally correct. It's not going to make a
big difference which is chosen.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: git, Erik Faye-Lund
In-Reply-To: <20090914120311.GA17172@sigill.intra.peff.net>
Compiling the following code gives a warning about unreachable code,
so it's clear that msvc doesn't simply ignore the directive. I'm not
saying that anyone suggested otherwise, I just wanted to know for
sure.
#include <stdio.h>
#include <stdlib.h>
void (*exit_fun)(int) = exit;
void __declspec(noreturn) die(void);
void die(void) { exit_fun(1); }
int main(void) { printf("hello!\n"); die(); printf("world!\n"); }
On Mon, Sep 14, 2009 at 2:03 PM, Jeff King <peff@peff.net> wrote:
> I think I am fine doing it either way. The NORETURN_PTR thing is a bit
> more elegant to me, but that is maybe just my gcc snobiness. We
> shouldn't have to change our code to accomodate MSVC's crappy noreturn
> handling. ;)
First of all, MSVC is not the only compiler that behaves this way. In
fact, GCC the only compiler I've found that behaves this way (but I
must admit, I only tested 4 different compilers, one of which (Comeau)
does not support noreturn at all AFAICT). That behavior might be
crappy, but it's not "MSVC's crappy noreturn handling" - it's
"non-GCC's crappy noreturn handling" :P
The arguments against each solution I see are these:
- abort() gives a run-time error instead of a compile-time warning, so
breakage is trickier to detect (on GCC, which seems to be the target
compiler for the vast majority of git-developers).
- NORETURN_PTR might be bit big of a hammer for a small problem, as it
"pollutes" the whole git source-tree instead of just usage.c.
Anyway, I don't care much what solution we pick. Either should work,
and if someone has strong preference, I'm OK with it.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Jeff King @ 2009-09-14 12:04 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140456l47cfce92yc44262c96b59bf2d@mail.gmail.com>
On Mon, Sep 14, 2009 at 01:56:29PM +0200, Erik Faye-Lund wrote:
> > That's odd. It's listed in my git-folder on GMail as sent to the
> > mailing-list, but I can't find it in any of the list-archives. They
> > were both sent through the same instance of "git send-email". I guess
> > I'll just re-send it.
>
> OK, I think I figured out why: For some reason, the From-field of the
> mail had gotten changed from kus...e@gmail.com to
> kus...e@googlemail.com, and that's not the address I'm subsribed to
> this list as. I hope whoever manages the list is able to remove my
> duplicates from the moderation-queue or something ;)
I doubt that is it; you don't have to be subscribed to post.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Jeff King @ 2009-09-14 12:03 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140440x2e189957uf66f36ff29bef302@mail.gmail.com>
On Mon, Sep 14, 2009 at 01:40:02PM +0200, Erik Faye-Lund wrote:
> > I didn't see a patch 1/2, so maybe it impacts this in some way, but by
> > itself, I don't think this patch is a good idea. See below.
>
> That's odd. It's listed in my git-folder on GMail as sent to the
> mailing-list, but I can't find it in any of the list-archives. They
> were both sent through the same instance of "git send-email". I guess
> I'll just re-send it. It shouldn't affect this patch directly, though.
Possibly it got swallowed by vger's list filter. The taboo list is here:
http://vger.kernel.org/majordomo-taboos.txt
> > I think the right solution to turn on NORETURN for (2) is to split it
> > into two cases: NORETURN and NORETURN_PTR. Gcc platforms can define both
> > identically, platforms under (2) above can define NORETURN_PTR as empty,
> > and (3) will keep both off.
>
> Yeah, this could work. I initially suggested doing this, but Junio
> suggested removing NORETURN all together. I didn't think that was a
> good idea for die() etc, thus this patch.
Doing it this way would keep warnings on compilers that could use them.
I am generally of the opinion that since most development happens on
gcc, it is "good enough" to let gcc warnings help us find broken code,
and then those fixes will be available to users of less-capable
compilers. And we don't have to bend over backwards in the code with
little hacks to trick all compilers into not issuing a warning (like
calling abort() after something we already know is going to exit).
The downside of that attitude is that code that is not exercised by gcc
builds does not get the benefit. And in the case of MSVC, there is
probably quite a bit of code in #ifdef's that gcc will never even parse.
So maybe a hack like abort() is worthwhile in this case.
> > #include <stdlib.h>
> > void (*exit_fun)(int) = exit;
> > static void die(void) __attribute__((__noreturn__));
> > static void die(void) { exit_fun(1); }
> > int main(void) { die(); }
>
> Well, it fails to compile ;)
>
> If your change it around this way (which is basically what 1/2 + a
> separate patch that is cooking in msysgit for a litte while longer is
> supposed to do), it does compiles without warnings even on the highest
> warning level:
>
> -static void die(void) __attribute__((__noreturn__));
> +static void __declspec(noreturn) die(void);
Hmm. So either it doesn't bother checking that noreturn functions don't
return, or it assumes that a function pointer may exit. Interesting,
but I guess it doesn't change the main point too much: it's not as
strict as gcc's checking.
> Yeah. So we need a portable (enough) way of showing it that it does
> die. How about abort()?
>
> -static void die(void) { exit_fun(1); }
> +static void die(void) { exit_fun(1); abort(); }
>
> Adding abort() makes the warning go away here, at least. And reaching
> this point is an error anyway, it means that one of the functions
> passed to set_die_routine() does not hold up it's guarantees. Your
> suggestion (double defines) would make this a compile-time warning
> instead of a run-time error, which I find much more elegant. However,
> it's questionable how much this means in reality - there's only two
> call-sites for set_die_routine() ATM. Do we expect it to grow a lot?
No, I don't think we expect it to grow. Mostly this is about documenting
our assumptions so that gcc can do the right thing in making die() a
noreturn function, which is what we actually care about. We would notice
very quickly, I think, if a die() handler did not actually exit.
I think I am fine doing it either way. The NORETURN_PTR thing is a bit
more elegant to me, but that is maybe just my gcc snobiness. We
shouldn't have to change our code to accomodate MSVC's crappy noreturn
handling. ;)
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 11:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Erik Faye-Lund
In-Reply-To: <40aa078e0909140440x2e189957uf66f36ff29bef302@mail.gmail.com>
On Mon, Sep 14, 2009 at 1:40 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> On Mon, Sep 14, 2009 at 12:57 PM, Jeff King <peff@peff.net> wrote:
>>
>> I didn't see a patch 1/2, so maybe it impacts this in some way, but by
>> itself, I don't think this patch is a good idea. See below.
>
> That's odd. It's listed in my git-folder on GMail as sent to the
> mailing-list, but I can't find it in any of the list-archives. They
> were both sent through the same instance of "git send-email". I guess
> I'll just re-send it.
OK, I think I figured out why: For some reason, the From-field of the
mail had gotten changed from kus...e@gmail.com to
kus...e@googlemail.com, and that's not the address I'm subsribed to
this list as. I hope whoever manages the list is able to remove my
duplicates from the moderation-queue or something ;)
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* [PATCH 1/2] increase portability of NORETURN declarations
From: Erik Faye-Lund @ 2009-09-14 11:49 UTC (permalink / raw)
To: git; +Cc: Erik Faye-Lund
Some compilers (including at least MSVC) supports NORETURN
on function declarations, but only before the function-name.
This patch makes it possible to define NORETURN for those compilers.
Signed-off-by: Erik Faye-Lund <kusmab...@gmail.com>
---
This patch requires specifying "-C 2" to "git am" to apply to the
current maint(7fb6bcf), but I suspect that it's not really needed
there. Supporting new compilers is going to require additional
patching anyway.
git-compat-util.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index e5e9f39..5876d91 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -177,9 +177,9 @@ extern char *gitbasename(char *);
#include "compat/bswap.h"
/* General helper functions */
-extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
-extern void die_errno(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
+extern NORETURN void usage(const char *err);
+extern NORETURN void die(const char *err, ...) __attribute__((format (printf, 1, 2)));
+extern NORETURN void die_errno(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
--
1.6.4.msysgit.0.16.gd92d4.dirty
^ permalink raw reply related
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 11:40 UTC (permalink / raw)
To: Jeff King; +Cc: git, Erik Faye-Lund
In-Reply-To: <20090914105750.GB9216@sigill.intra.peff.net>
On Mon, Sep 14, 2009 at 12:57 PM, Jeff King <peff@peff.net> wrote:
>
> I didn't see a patch 1/2, so maybe it impacts this in some way, but by
> itself, I don't think this patch is a good idea. See below.
That's odd. It's listed in my git-folder on GMail as sent to the
mailing-list, but I can't find it in any of the list-archives. They
were both sent through the same instance of "git send-email". I guess
I'll just re-send it. It shouldn't affect this patch directly, though.
The patch basically moved the NORETURN before the function-name, as
this is a placement where more compilers supports
declaration-specifications.
>> ---
>>
>> __attribute__((noreturn)) is, according to the GCC documentation, about
>> two things: code generation (performance, really) and warnings.
>>
>> On the warnings-side, we need to keep the code warning-free for
>> compilers who doesn't support noreturn anyway, so hiding potential
>> warnings through this mechanism is probably not a good idea in the
>> first place.
>
> [Your justification text would almost certainly be useful as part of the
> commit message itself, and should go there.]
OK, I'll include it in the next round.
> Unfortunately, this patch _introduces_ warnings when running with gcc,
> as it now thinks those function pointers return (which means it thinks
> die() returns). So simply removing the NORETURN is not a good idea.
Yeah, this is unacceptable. I can't believe I missed this - sorry about that!
> If I understand you correctly, the problem is that there are actually
> three classes of compilers:
>
> 1. Ones which understand some NORETURN syntax for both functions and
> function pointers, and correctly trace returns through both (e.g.,
> gcc).
>
> 2. Ones which understand some NORETURN syntax for just functions, and
> complain about it on function pointers. We currently turn off
> NORETURN for these compilers (from your commit message, MSVC,
> for example).
>
> 3. Ones which have no concept of NORETURN at all.
>
> I think the right solution to turn on NORETURN for (2) is to split it
> into two cases: NORETURN and NORETURN_PTR. Gcc platforms can define both
> identically, platforms under (2) above can define NORETURN_PTR as empty,
> and (3) will keep both off.
Yeah, this could work. I initially suggested doing this, but Junio
suggested removing NORETURN all together. I didn't think that was a
good idea for die() etc, thus this patch.
> I do have to wonder, though. What do compilers that fall under (2) do
> with calls to function pointers from NORETURN functions? Do they assume
> they don't return, or that they do? Or do they not check that NORETURN
> functions actually don't return?
>
> I.e., what does this program do under MSVC:
>
> #include <stdlib.h>
> void (*exit_fun)(int) = exit;
> static void die(void) __attribute__((__noreturn__));
> static void die(void) { exit_fun(1); }
> int main(void) { die(); }
Well, it fails to compile ;)
If your change it around this way (which is basically what 1/2 + a
separate patch that is cooking in msysgit for a litte while longer is
supposed to do), it does compiles without warnings even on the highest
warning level:
-static void die(void) __attribute__((__noreturn__));
+static void __declspec(noreturn) die(void);
> In gcc, it rightly complains:
>
> foo.c: In function ‘die’:
> foo.c:4: warning: ‘noreturn’ function does return
Yeah. So we need a portable (enough) way of showing it that it does
die. How about abort()?
-static void die(void) { exit_fun(1); }
+static void die(void) { exit_fun(1); abort(); }
Adding abort() makes the warning go away here, at least. And reaching
this point is an error anyway, it means that one of the functions
passed to set_die_routine() does not hold up it's guarantees. Your
suggestion (double defines) would make this a compile-time warning
instead of a run-time error, which I find much more elegant. However,
it's questionable how much this means in reality - there's only two
call-sites for set_die_routine() ATM. Do we expect it to grow a lot?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: could not detach HEAD error didn't identify the cause of the issue
From: Jeff King @ 2009-09-14 11:22 UTC (permalink / raw)
To: Ben Bradshaw; +Cc: git
In-Reply-To: <4AAD8AE0.9070305@catalyst.net.nz>
On Mon, Sep 14, 2009 at 12:14:24PM +1200, Ben Bradshaw wrote:
> I was asked to post this issue to the list, I've just had git tell me it
> can't detach HEAD which left me scratching mine as to the cause and fix.
> Turns out if I have local untracked files that the remote branch also
> has then this error will trigger. I have included my shell backlog
> (client data removed). In this example the site_map folder was present
> on master and I had a local, untracked copy.
>
> git can obviosly detect this issue and stop my local copy getting in a
> bad state, but an error message such as "sites/all/modules/site_map/ is
> present in HEAD but is untracked locally, unable to apply changes" (or
> something to point the finger) would be much appreciated.
I couldn't reproduce it here; I get such a message.
# set up forked repo, "another" exists only on master
$ mkdir repo && cd repo
$ git init
$ echo content >file && git add file && git commit -m base
$ echo content >another && git add another && git commit -m another
$ git checkout -b other HEAD^
$ echo changes >file && git commit -a -m changes
# add untracked "another" here
$ echo untracked >another
# try rebase
$ git rebase master
First, rewinding head to replay your work on top of it...
error: Untracked working tree file 'another' would be overwritten by merge.
could not detach HEAD
# try git pull --rebase, in case it hides the message
$ git config branch.other.remote .
$ git config branch.other.merge refs/heads/master
$ git pull --rebase
From .
* branch master -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
error: Untracked working tree file 'another' would be overwritten by merge.
could not detach HEAD
I'll admit the "could not detach HEAD" message would probably be better as:
rebase: unable to move HEAD to 'master', aborting rebase
or something similar.
What version of git are you using? What does my test case above produce
for you?
-Peff
^ permalink raw reply
* Re: Confusing git pull error message
From: Jeff King @ 2009-09-14 11:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Tapsell, Git List
In-Reply-To: <7v1vmar353.fsf@alter.siamese.dyndns.org>
On Sun, Sep 13, 2009 at 01:38:48PM -0700, Junio C Hamano wrote:
> I saw some discussion on improving the wording. Here is what I plan to
> commit.
>
> diff --git a/git-pull.sh b/git-pull.sh
> index 0bbd5bf..2c2fa79 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -89,6 +89,8 @@ error_on_no_merge_candidates () {
> done
>
> curr_branch=${curr_branch#refs/heads/}
> + upstream=$(git config "branch.$curr_branch.merge" ||
> + git config "branch.$curr_branch.rebase")
Argh, I made a mistake in my original patch which was retained in your
version. For some reason I was thinking that "branch.*.rebase" was an
_alternative_ to branch.*.merge, but it is in fact a bool that modifies
how we interpret branch.*.merge (I think when the feature was originally
discussed, that was one such proposal, and as I am not a user of the
feature, I proceeded with a totally bogus mental model since then).
So this really should read simply:
upstream=$(git config "branch.$curr_branch.merge")
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] remove NORETURN from function pointers
From: Jeff King @ 2009-09-14 10:57 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, Erik Faye-Lund
In-Reply-To: <1252923370-5768-2-git-send-email-kusmabite@gmail.com>
On Mon, Sep 14, 2009 at 12:16:10PM +0200, Erik Faye-Lund wrote:
> From: Erik Faye-Lund <kusmabite@googlemail.com>
>
> Some compilers (including at least MSVC and ARM RVDS) supports
> NORETURN on function declarations, but not on function pointers.
>
> This patch makes it possible to define NORETURN for these compilers.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
I didn't see a patch 1/2, so maybe it impacts this in some way, but by
itself, I don't think this patch is a good idea. See below.
> ---
>
> __attribute__((noreturn)) is, according to the GCC documentation, about
> two things: code generation (performance, really) and warnings.
>
> On the warnings-side, we need to keep the code warning-free for
> compilers who doesn't support noreturn anyway, so hiding potential
> warnings through this mechanism is probably not a good idea in the
> first place.
[Your justification text would almost certainly be useful as part of the
commit message itself, and should go there.]
Unfortunately, this patch _introduces_ warnings when running with gcc,
as it now thinks those function pointers return (which means it thinks
die() returns). So simply removing the NORETURN is not a good idea.
If I understand you correctly, the problem is that there are actually
three classes of compilers:
1. Ones which understand some NORETURN syntax for both functions and
function pointers, and correctly trace returns through both (e.g.,
gcc).
2. Ones which understand some NORETURN syntax for just functions, and
complain about it on function pointers. We currently turn off
NORETURN for these compilers (from your commit message, MSVC,
for example).
3. Ones which have no concept of NORETURN at all.
I think the right solution to turn on NORETURN for (2) is to split it
into two cases: NORETURN and NORETURN_PTR. Gcc platforms can define both
identically, platforms under (2) above can define NORETURN_PTR as empty,
and (3) will keep both off.
I do have to wonder, though. What do compilers that fall under (2) do
with calls to function pointers from NORETURN functions? Do they assume
they don't return, or that they do? Or do they not check that NORETURN
functions actually don't return?
I.e., what does this program do under MSVC:
#include <stdlib.h>
void (*exit_fun)(int) = exit;
static void die(void) __attribute__((__noreturn__));
static void die(void) { exit_fun(1); }
int main(void) { die(); }
In gcc, it rightly complains:
foo.c: In function ‘die’:
foo.c:4: warning: ‘noreturn’ function does return
-Peff
^ permalink raw reply
* [PATCH 2/2] remove NORETURN from function pointers
From: Erik Faye-Lund @ 2009-09-14 10:16 UTC (permalink / raw)
To: git; +Cc: Erik Faye-Lund, Erik Faye-Lund
In-Reply-To: <1252923370-5768-1-git-send-email-kusmabite@gmail.com>
From: Erik Faye-Lund <kusmabite@googlemail.com>
Some compilers (including at least MSVC and ARM RVDS) supports
NORETURN on function declarations, but not on function pointers.
This patch makes it possible to define NORETURN for these compilers.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
__attribute__((noreturn)) is, according to the GCC documentation, about
two things: code generation (performance, really) and warnings.
On the warnings-side, we need to keep the code warning-free for
compilers who doesn't support noreturn anyway, so hiding potential
warnings through this mechanism is probably not a good idea in the
first place.
We still want the performance-side of it, though. However, the only
place this really makes a difference is to die and it's variants, since
they can potentially be called many times (or so it seems from the
compiler's point of view without a noreturn declaration).
The function pointers are only called once we're already exiting, and
they have only one potential call-site.
I hope this all makes sense ;)
git-compat-util.h | 2 +-
usage.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 5876d91..15fe08e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -183,7 +183,7 @@ extern NORETURN void die_errno(const char *err, ...) __attribute__((format (prin
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2)));
-extern void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
+extern void set_die_routine(void (*routine)(const char *err, va_list params));
extern int prefixcmp(const char *str, const char *prefix);
extern time_t tm_to_time_t(const struct tm *tm);
diff --git a/usage.c b/usage.c
index b6aea45..18d7f43 100644
--- a/usage.c
+++ b/usage.c
@@ -36,12 +36,12 @@ static void warn_builtin(const char *warn, va_list params)
/* If we are in a dlopen()ed .so write to a global variable would segfault
* (ugh), so keep things static. */
-static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
-static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
+static void (*usage_routine)(const char *err) = usage_builtin;
+static void (*die_routine)(const char *err, va_list params) = die_builtin;
static void (*error_routine)(const char *err, va_list params) = error_builtin;
static void (*warn_routine)(const char *err, va_list params) = warn_builtin;
-void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN)
+void set_die_routine(void (*routine)(const char *err, va_list params))
{
die_routine = routine;
}
--
1.6.4.msysgit.0.16.gd92d4.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox