delta/libgit2.git/src/common.h, branch ethomson/github_actions github.com: libgit2/libgit2.git assert: optionally fall-back to assert(3) 2020-05-11T19:13:54+00:00 Edward Thomson ethomson@edwardthomson.com 2020-01-12T10:31:07+00:00 a95096ba5f72db71422ffd9ea6630160387b97c0 Fall back to the system assert(3) in debug builds, which may aide in debugging. "Safe" assertions can be enabled in debug builds by setting GIT_ASSERT_HARD=0. Similarly, hard assertions can be enabled in release builds by setting GIT_ASSERT_HARD to nonzero. 
Fall back to the system assert(3) in debug builds, which may aide
in debugging.

"Safe" assertions can be enabled in debug builds by setting
GIT_ASSERT_HARD=0.  Similarly, hard assertions can be enabled in
release builds by setting GIT_ASSERT_HARD to nonzero.
Introduce GIT_ASSERT macros 2020-05-11T19:13:54+00:00 Edward Thomson ethomson@edwardthomson.com 2019-12-09T02:37:34+00:00 abe2efe1ff84d423ef5f104b1e95e9ef66442c0f Provide macros to replace usages of `assert`. A true `assert` is punishing as a library. Instead we should do our best to not crash. GIT_ASSERT_ARG(x) will now assert that the given argument complies to some format and sets an error message and returns `-1` if it does not. GIT_ASSERT(x) is for internal usage, and available as an internal consistency check. It will set an error message and return `-1` in the event of failure. 
Provide macros to replace usages of `assert`.  A true `assert` is
punishing as a library.  Instead we should do our best to not crash.

GIT_ASSERT_ARG(x) will now assert that the given argument complies to
some format and sets an error message and returns `-1` if it does not.

GIT_ASSERT(x) is for internal usage, and available as an internal
consistency check.  It will set an error message and return `-1` in the
event of failure.
posix: remove superseded POSIX regex wrappers 2019-09-21T13:26:19+00:00 Patrick Steinhardt ps@pks.im 2019-09-12T12:29:28+00:00 f585b129e242bacb4cbecc30a6af727e5b4c2f28 The old POSIX regex wrappers have been superseded by our own regexp API that provides a higher-level abstraction. Remove the POSIX wrappers in favor of the new one. 
The old POSIX regex wrappers have been superseded by our own regexp API
that provides a higher-level abstraction. Remove the POSIX wrappers in
favor of the new one.
win32: move type definitions for improved inclusion 2019-05-19T10:12:13+00:00 Edward Thomson ethomson@edwardthomson.com 2019-01-13T21:10:50+00:00 fe1fb36e57a35c73740fc7ff2286fd0b7b3c0a20 Move some win32 type definitions to a standalone file so that they can be included before other header files try to use the definitions. 
Move some win32 type definitions to a standalone file so that they can
be included before other header files try to use the definitions.
regexec: prefix all regexec function calls with p_ 2019-05-19T10:10:08+00:00 Edward Thomson ethomson@edwardthomson.com 2019-01-12T23:06:39+00:00 02683b20c0775dab28d72727cc97a96ec77cb20c Prefix all the calls to the the regexec family of functions with `p_`. This allows us to swap out all the regular expression functions with our own implementation. Move the declarations to `posix_regex.h` for simpler inclusion. 
Prefix all the calls to the the regexec family of functions with `p_`.
This allows us to swap out all the regular expression functions with our
own implementation.  Move the declarations to `posix_regex.h` for
simpler inclusion.
deprecation: ensure we GIT_EXTERN deprecated funcs 2019-02-14T11:57:05+00:00 Edward Thomson ethomson@edwardthomson.com 2019-02-13T23:26:54+00:00 24ac9e0c97ff9f20d096b4d93663276bc8bb2de1 Although the error functions were deprecated, we did not properly mark them as deprecated. We need to include the `deprecated.h` file in order to ensure that the functions get their export attributes. Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or those functions will also not get their export attributes. Define that only on the tests and examples. 
Although the error functions were deprecated, we did not properly mark
them as deprecated.  We need to include the `deprecated.h` file in order
to ensure that the functions get their export attributes.

Similarly, do not define `GIT_DEPRECATE_HARD` within the library, or
those functions will also not get their export attributes.  Define that
only on the tests and examples.
git_error: use new names in internal APIs and usage 2019-01-22T22:30:35+00:00 Edward Thomson ethomson@edwardthomson.com 2018-12-27T19:47:34+00:00 f673e232afe22eb865cdc915e55a2df6493f0fbb Move to the `git_error` name in the internal API for error-related functions. 
Move to the `git_error` name in the internal API for error-related
functions.
treewide: avoid use of `inline` attribute 2018-07-13T06:25:12+00:00 Patrick Steinhardt ps@pks.im 2018-06-25T09:55:13+00:00 f347a441c81c4e16dd54de07c5070eca8fccd5c8 ISO C90 does not specify the `inline` attribute, and as such we cannot use it in our code. While we already use `__inline` when building in Microsoft Visual Studio, we should also be using the `__inline__` attribute from GCC/Clang. Otherwise, if we're using neither MSVC nor GCC/Clang, we should simply avoid using `inline` at all and just define functions as static. This commit adjusts our own `GIT_INLINE` macro as well as the inline macros specified by khash and xdiff. This allows us to enable strict C90 mode in a later commit. 
ISO C90 does not specify the `inline` attribute, and as such we cannot
use it in our code. While we already use `__inline` when building in
Microsoft Visual Studio, we should also be using the `__inline__`
attribute from GCC/Clang. Otherwise, if we're using neither MSVC nor
GCC/Clang, we should simply avoid using `inline` at all and just define
functions as static.

This commit adjusts our own `GIT_INLINE` macro as well as the inline
macros specified by khash and xdiff. This allows us to enable strict C90
mode in a later commit.
Merge pull request #4489 from libgit2/ethomson/conflicts_crlf 2018-02-04T10:27:39+00:00 Edward Thomson ethomson@edwardthomson.com 2018-02-04T10:27:39+00:00 26f5d36d2f14dc1d711ed0a2c844ef4d7887a9b3 Conflict markers should match EOL style in conflicting files 
Conflict markers should match EOL style in conflicting files
 consistent header guards 2018-02-01T23:56:33+00:00 Edward Thomson ethomson@edwardthomson.com 2018-02-01T23:55:48+00:00 abb04caa2f74bb4783eb87202a904c0c3517df85 use consistent names for the #include / #define header guard pattern. 
use consistent names for the #include / #define header guard pattern.