git/git-compat-util.h, branch gitk-resize-error

Merge branch 'ab/usage-die-message'

2022-01-10T19:52:53Z

Code clean-up to hide vreportf() from public API. * ab/usage-die-message: config API: use get_error_routine(), not vreportf() usage.c + gc: add and use a die_message_errno() gc: return from cmd_gc(), don't call exit() usage.c API users: use die_message() for error() + exit 128 usage.c API users: use die_message() for "fatal :" + exit 128 usage.c: add a die_message() routine

Merge branch 'jc/flex-array-definition'

2022-01-05T22:01:27Z

The conditions to choose different definitions of the FLEX_ARRAY macro for vendor compilers has been simplified to make it easier to maintain. * jc/flex-array-definition: flex-array: simplify compiler-specific workaround

Merge branch 'cb/mingw-gmtime-r'

2021-12-10T22:35:15Z

Build fix on Windows. * cb/mingw-gmtime-r: mingw: avoid fallback for {local,gm}time_r()

Merge branch 'bc/require-c99'

2021-12-10T22:35:14Z

Weather balloon to break people with compilers that do not support C99. * bc/require-c99: git-compat-util: add a test balloon for C99 support

flex-array: simplify compiler-specific workaround

2021-12-09T01:45:16Z

We use "type array[];" syntax for the flex-array member at the end of a struct under C99 or later, except when we are building with older SUNPRO_C compilers. As we find more vendor compilers that claim to grok C99 but not understand the flex-array syntax, the existing "If we are using C99, but not with these compilers..." conditional will keep growing. Make it more manageable by listing vendor-specific exceptions earlier, with the expectation that new exceptions will not be combined into existing ones to make the condition longer, and instead will be implemented as a new "#elif" in the cascade of similar to old SUNPRO_C, we can just add a single line #elif defined(_MSC_VER) immediately before "#elif defined(__GNUC__)" to cause us to fallback to the safer but a bit wasteful version. Signed-off-by: Junio C Hamano

config API: use get_error_routine(), not vreportf()

2021-12-07T21:25:16Z

Change the git_die_config() function added in 5a80e97c827 (config: add `git_die_config()` to the config-set API, 2014-08-07) to use the public callbacks in the usage.[ch] API instead of the the underlying vreportf() function. In preceding commits the rest of the vreportf() users outside of usage.c was migrated to die_message(), so we can now make it "static". Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

usage.c + gc: add and use a die_message_errno()

2021-12-07T21:25:16Z

Change the "error: " output when we exit with 128 due to gc.log errors to use a "fatal: " prefix instead. To do this add a die_message_errno() a sibling function to the die_errno() added in a preceding commit. Before this we'd expect report_last_gc_error() to return -1 from error_errno() in this case. It already treated a status of 0 and 1 specially. Let's just document that anything that's not 0 or 1 should be returned. We could also retain the "ret < 0" behavior here without hardcoding 128 by returning -128, and having the caller do a "return -ret", but I think this makes more sense, and preserves the path from die_message*()'s return value to the "return" without hardcoding "128". Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

usage.c: add a die_message() routine

2021-12-07T21:25:15Z

We have code in various places that would like to call die(), but wants to defer the exit(128) it would invoke, e.g. to print an additional message, or adjust the exit code. Add a die_message() helper routine to bridge this gap in the API. Functionally this behaves just like the error() routine, except it'll print a "fatal: " prefix, and it will return with 128 instead of -1, this is so that caller can pass the return value to "exit()", instead of having to hardcode "exit(128)". Note that as with the other routines the "die_message_builtin" needs to return "void" and otherwise conform to the "report_fn" signature. As we'll see in a subsequent commit callers will want to replace e.g. their default "die_routine" with a "die_message_routine". For now we're just adding the routine and making die_builtin() in usage.c itself use it. In order to do that we need to add a get_die_message_routine() function, which works like the other get_*_routine() functions in usage.c. There is no set_die_message_rotine(), as it hasn't been needed yet. We can add it if we ever need it. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

git-compat-util: add a test balloon for C99 support

2021-12-01T22:50:01Z

The C99 standard was released in January 1999, now 22 years ago. It provides a variety of useful features, including variadic arguments for macros, declarations after statements, designated initializers, and a wide variety of other useful features, many of which we already use. We'd like to take advantage of these features, but we want to be cautious. As far as we know, all major compilers now support C99 or a later C standard, such as C11 or C17. POSIX has required C99 support as a requirement for the 2001 revision, so we can safely assume any POSIX system which we are interested in supporting has C99. Even MSVC, long a holdout against modern C, now supports both C11 and C17 with an appropriate update. Moreover, even if people are using an older version of MSVC on these systems, they will generally need some implementation of the standard Unix utilities for the testsuite, and GNU coreutils, the most common option, has required C99 since 2009. Therefore, we can safely assume that a suitable version of GCC or clang is available to users even if their version of MSVC is not sufficiently capable. Let's add a test balloon to git-compat-util.h to see if anyone is using an older compiler. We'll add a comment telling people how to enable this functionality on GCC and Clang, even though modern versions of both will automatically do the right thing, and ask people still experiencing a problem to report that to us on the list. Note that C89 compilers don't provide the __STDC_VERSION__ macro, so we use a well-known hack of using "- 0". On compilers with this macro, it doesn't change the value, and on C89 compilers, the macro will be replaced with nothing, and our value will be 0. For sparse, we explicitly request the gnu99 style because we've traditionally taken advantage of some GCC- and clang-specific extensions when available and we'd like to retain the ability to do that. sparse also defaults to C89 without it, so things will fail for us if we don't. Update the cmake configuration to require C11 for MSVC. We do this because this will make MSVC to use C11, since it does not explicitly support C99. We do this with a compiler options because setting the C_STANDARD option does not work in our CI on MSVC and at the moment, we don't want to require C11 for Unix compilers. In the Makefile, don't set any compiler flags for the compiler itself, since on some systems, such as FreeBSD, we actually need C11, and asking for C99 causes things to fail to compile. The error message should make it obvious what's going wrong and allow a user to set the appropriate option when building in the event they're using a Unix compiler that doesn't support it by default. Signed-off-by: brian m. carlson Signed-off-by: Junio C Hamano

Merge branch 'mc/clean-smudge-with-llp64'

2021-11-29T23:41:51Z

The clean/smudge conversion code path has been prepared to better work on platforms where ulong is narrower than size_t. * mc/clean-smudge-with-llp64: clean/smudge: allow clean filters to process extremely large files odb: guard against data loss checking out a huge file git-compat-util: introduce more size_t helpers odb: teach read_blob_entry to use size_t t1051: introduce a smudge filter test for extremely large files test-lib: add prerequisite for 64-bit platforms test-tool genzeros: generate large amounts of data more efficiently test-genzeros: allow more than 2G zeros in Windows