|
aab8f87b
|
2018-03-14T10:27:13
|
|
win32: crtdbg: internalize implementation of allocators
The crtdbg allocators are currently being implemented as inline
functions as part of the "w32_crtdbg_stacktrace.h" header. As we are
moving towards pluggable allocators with the help of function pointers,
though, we cannot make use of inlining anymore. Instead, we can only
have a single implementation of these allocating functions.
Move all implementations of the crtdbg allocators into
"w32_crtdbg_stacktrace.c".
|
|
|
9865cd16
|
2018-03-20T14:23:49
|
|
alloc: make memory allocators use function pointers
Currently, our memory allocators are being redirected to the correct
implementation at compile time by simply using macros. In order to make
them swappable at runtime, this commit reshuffles that by instead making
use of a global "git_allocator" structure, whose pointers are set up to
reference the allocator functions. Like this, it becomes easy to swap
out allocators by simply setting these function pointers.
In order to initialize a "git_allocator", our provided allocators
"stdalloc" and "crtdbg" both provide an init function. This is being
called to initialize a passed in allocator struct and set up its members
correctly.
No support is yet included to enable users of libgit2 to switch out the
memory allocator at a global level.
|
|
|
496b0df2
|
2018-03-14T10:28:50
|
|
win32: crtdbg: provide independent `free` function
Currently, the `git__free` function is being defined in a single place,
only, disregarding whether we use our standard allocators or the crtdbg
allocators. This makes it a bit harder to convert our code base to use
pluggable allocators, and furthermore makes the border between our two
allocators a bit more blurry.
Implement a separate `git__crtdbg__free` function for the crtdbg
allocator in order to completely separate both allocator
implementations.
|
|
abb04caa
|
2018-02-01T15:55:48
|
|
consistent header guards
use consistent names for the #include / #define header guard pattern.
|
|
|
0c7f49dd
|
2017-06-30T13:39:01
|
|
Make sure to always include "common.h" first
Next to including several files, our "common.h" header also declares
various macros which are then used throughout the project. As such, we
have to make sure to always include this file first in all
implementation files. Otherwise, we might encounter problems or even
silent behavioural differences due to macros or defines not being
defined as they should be. So in fact, our header and implementation
files should make sure to always include "common.h" first.
This commit does so by establishing a common include pattern. Header
files inside of "src" will now always include "common.h" as its first
other file, separated by a newline from all the other includes to make
it stand out as special. There are two cases for the implementation
files. If they do have a matching header file, they will always include
this one first, leading to "common.h" being transitively included as
first file. If they do not have a matching header file, they instead
include "common.h" as first file themselves.
This fixes the outlined problems and will become our standard practice
for header and source files inside of the "src/" from now on.
|
|
|
459fb8fe
|
2017-06-30T15:35:46
|
|
win32: fix circular include deps with w32_crtdbg
The current order of declarations and includes between "common.h" and
"w32_crtdbg_stacktrace.h" is rather complicated. Both header files make
use of things defined in the other one and are thus circularly dependent
on each other. This makes it currently impossible to compile the
"w32_crtdbg_stacktrace.c" file when including "common.h" inside of
"w32_crtdbg_stacktrace.h".
We can disentangle the mess by moving declaration of the inline crtdbg
functions into the "w32_crtdbg_stacktrace.h" file and adding additional
includes inside of it, such that all required functions are available to
it. This allows us to break the dependency cycle.
|
|
93b42728
|
2015-06-09T14:38:30
|
|
Include stacktrace summary in memory leak output.
|