From 8d4679fe0995affd40301169fbfe6d679561bc64 Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Thu, 13 Jun 2019 04:49:44 -0700 Subject: [PATCH 1/4] poll (mingw): allow compiling with GCC 8 and DEVELOPER=1 The return type of the `GetProcAddress()` function is `FARPROC` which evaluates to `long long int (*)()`, i.e. it cannot be cast to the correct function signature by GCC 8. To work around that, we first cast to `void *` and go on with our merry lives. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano --- compat/poll/poll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index 4459408c7d0..8b07edb0fec 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -149,7 +149,7 @@ win32_compute_revents (HANDLE h, int *p_sought) case FILE_TYPE_PIPE: if (!once_only) { - NtQueryInformationFile = (PNtQueryInformationFile) + NtQueryInformationFile = (PNtQueryInformationFile)(void (*)(void)) GetProcAddress (GetModuleHandle ("ntdll.dll"), "NtQueryInformationFile"); once_only = TRUE; From 08e0450690b8f4aa0f51d8c096520817f96de3dd Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Thu, 13 Jun 2019 04:49:45 -0700 Subject: [PATCH 2/4] kwset: allow building with GCC 8 The kwset functionality makes use of the obstack code, which expects to be handed a function that can allocate large chunks of data. It expects that function to accept a `size` parameter of type `long`. This upsets GCC 8 on Windows, because `long` does not have the same bit size as `size_t` there. Now, the proper thing to do would be to switch to `size_t`. But this would make us deviate from the "upstream" code even further, making it hard to synchronize with newer versions, and also it would be quite involved because that `long` type is so invasive in that code. Let's punt, and instead provide a super small wrapper around `xmalloc()`. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano --- kwset.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/kwset.c b/kwset.c index 4fb6455acaf..efc2ff41bc3 100644 --- a/kwset.c +++ b/kwset.c @@ -38,7 +38,13 @@ #include "compat/obstack.h" #define NCHAR (UCHAR_MAX + 1) -#define obstack_chunk_alloc xmalloc +/* adapter for `xmalloc()`, which takes `size_t`, not `long` */ +static void *obstack_chunk_alloc(long size) +{ + if (size < 0) + BUG("Cannot allocate a negative amount: %ld", size); + return xmalloc(size); +} #define obstack_chunk_free free #define U(c) ((unsigned char) (c)) From 4fa42df972dc40fa3b50195ace838f2269da977a Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Thu, 13 Jun 2019 04:49:46 -0700 Subject: [PATCH 3/4] winansi: simplify loading the GetCurrentConsoleFontEx() function We introduced helper macros to simplify loading functions dynamically. Might just as well use them. This also side-steps a compiler warning when building with GCC v8.x: it would complain about casting between incompatible function pointers. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano --- compat/winansi.c | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/compat/winansi.c b/compat/winansi.c index f4f08237f9e..a29d34ef448 100644 --- a/compat/winansi.c +++ b/compat/winansi.c @@ -7,6 +7,7 @@ #include #include #include "win32.h" +#include "win32/lazyload.h" static int fd_is_interactive[3] = { 0, 0, 0 }; #define FD_CONSOLE 0x1 @@ -41,26 +42,21 @@ typedef struct _CONSOLE_FONT_INFOEX { #endif #endif -typedef BOOL (WINAPI *PGETCURRENTCONSOLEFONTEX)(HANDLE, BOOL, - PCONSOLE_FONT_INFOEX); - static void warn_if_raster_font(void) { DWORD fontFamily = 0; - PGETCURRENTCONSOLEFONTEX pGetCurrentConsoleFontEx; + DECLARE_PROC_ADDR(kernel32.dll, BOOL, GetCurrentConsoleFontEx, + HANDLE, BOOL, PCONSOLE_FONT_INFOEX); /* don't bother if output was ascii only */ if (!non_ascii_used) return; /* GetCurrentConsoleFontEx is available since Vista */ - pGetCurrentConsoleFontEx = (PGETCURRENTCONSOLEFONTEX) GetProcAddress( - GetModuleHandle("kernel32.dll"), - "GetCurrentConsoleFontEx"); - if (pGetCurrentConsoleFontEx) { + if (INIT_PROC_ADDR(GetCurrentConsoleFontEx)) { CONSOLE_FONT_INFOEX cfi; cfi.cbSize = sizeof(cfi); - if (pGetCurrentConsoleFontEx(console, 0, &cfi)) + if (GetCurrentConsoleFontEx(console, 0, &cfi)) fontFamily = cfi.FontFamily; } else { /* pre-Vista: check default console font in registry */ From 9dae4fe79f85dd0eaf41215bea76c68b65398fbc Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Thu, 13 Jun 2019 04:49:47 -0700 Subject: [PATCH 4/4] config: avoid calling `labs()` on too-large data type The `labs()` function operates, as the initial `l` suggests, on `long` parameters. However, in `config.c` we tried to use it on values of type `intmax_t`. This problem was found by GCC v9.x. To fix it, let's just "unroll" the function (i.e. negate the value if it is negative). Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano --- config.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config.c b/config.c index 296a6d9cc41..01c6e9df23c 100644 --- a/config.c +++ b/config.c @@ -869,9 +869,9 @@ static int git_parse_signed(const char *value, intmax_t *ret, intmax_t max) errno = EINVAL; return 0; } - uval = labs(val); + uval = val < 0 ? -val : val; uval *= factor; - if (uval > max || labs(val) > uval) { + if (uval > max || (val < 0 ? -val : val) > uval) { errno = ERANGE; return 0; }