delta/libgit2.git/src/hash.c, branch ethomson/github_actions github.com: libgit2/libgit2.git hash: fix missing error return on production builds 2019-06-27T11:58:02+00:00 Patrick Steinhardt ps@pks.im 2019-06-27T11:54:55+00:00 7fd3f32b49488cefae566ed99ab577ece5c3c89d When no hash algorithm has been initialized in a given hash context, then we will simply `assert` and not return a value at all. This works just fine in debug builds, but on non-debug builds the assert will be converted to a no-op and thus we do not have a proper return value. Fix this by returning an error code in addition to the asserts. 
When no hash algorithm has been initialized in a given hash context,
then we will simply `assert` and not return a value at all. This works
just fine in debug builds, but on non-debug builds the assert will be
converted to a no-op and thus we do not have a proper return value.

Fix this by returning an error code in addition to the asserts.
hash: add ability to distinguish algorithms 2019-06-24T16:33:22+00:00 Patrick Steinhardt ps@pks.im 2019-02-22T13:38:31+00:00 b7187ed745a066806881d71d248cca66d7cd3f0a Create an enum that allows us to distinguish between different hashing algorithms. This enum is embedded into each `git_hash_ctx` and will instruct the code to which hashing function the particular request shall be dispatched. As we do not yet have multiple hashing algorithms, we simply initialize the hash algorithm to always be SHA1. At a later point, we will have to extend the `git_hash_init_ctx` function to get as parameter which algorithm shall be used. 
Create an enum that allows us to distinguish between different
hashing algorithms. This enum is embedded into each
`git_hash_ctx` and will instruct the code to which hashing
function the particular request shall be dispatched.

As we do not yet have multiple hashing algorithms, we simply
initialize the hash algorithm to always be SHA1. At a later
point, we will have to extend the `git_hash_init_ctx` function to
get as parameter which algorithm shall be used.
hash: move SHA1 implementations to its own hashing context 2019-06-24T16:33:22+00:00 Patrick Steinhardt ps@pks.im 2019-02-22T13:32:40+00:00 8832172e9b73bc4edf938fbac6db850eef436699 Create a separate `git_hash_sha1_ctx` structure that is specific to the SHA1 implementation and move all SHA1 functions over to use that one instead of the generic `git_hash_ctx`. The `git_hash_ctx` for now simply has a union containing this single SHA1 implementation, only, without any mechanism to distinguish between different algortihms. 
Create a separate `git_hash_sha1_ctx` structure that is specific
to the SHA1 implementation and move all SHA1 functions over to
use that one instead of the generic `git_hash_ctx`. The
`git_hash_ctx` for now simply has a union containing this single
SHA1 implementation, only, without any mechanism to distinguish
between different algortihms.
hash: split into generic and SHA1-specific interface 2019-06-24T16:33:22+00:00 Patrick Steinhardt ps@pks.im 2019-04-05T08:59:46+00:00 d46d3b539b3e0ed3871d2ac22271a6469ed7c215 As a preparatory step to allow multiple hashing APIs to exist at the same time, split the hashing functions into one layer for generic hashing and one layer for SHA1-specific hashing. Right now, this is simply an additional indirection layer that doesn't yet serve any purpose. In the future, the generic API will be extended to allow for choosing which hash to use, though, by simply passing an enum to the hash context initialization function. This is necessary as a first step to be ready for Git's move to SHA256. 
As a preparatory step to allow multiple hashing APIs to exist at
the same time, split the hashing functions into one layer for generic
hashing and one layer for SHA1-specific hashing. Right now, this is
simply an additional indirection layer that doesn't yet serve any
purpose. In the future, the generic API will be extended to allow for
choosing which hash to use, though, by simply passing an enum to the
hash context initialization function. This is necessary as a first step
to be ready for Git's move to SHA256.
Make sure to always include "common.h" first 2017-07-03T08:51:48+00:00 Patrick Steinhardt ps@pks.im 2017-06-30T11:39:01+00:00 0c7f49dd4316b332f30b4ea72a657bace41e1245 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. 
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.
update copyrights 2013-01-08T23:31:27+00:00 Edward Thomson ethomson@edwardthomson.com 2013-01-08T23:07:25+00:00 359fc2d241ac407bdf9bf0d28715705f01ca6360 






Remove git_hash_ctx_new - callers now _ctx_init()
2012-11-13T16:23:05+00:00

Edward Thomson
ethomson@microsoft.com

2012-11-13T01:22:49+00:00

603bee07918b50051d7bb45722932fc409b38a67












Win32 CryptoAPI and CNG support for SHA1
2012-11-13T16:23:05+00:00

Edward Thomson
ethomson@edwardthomson.com

2012-11-05T18:37:15+00:00

d6fb09240913c9756de5f4a2462062008ebac252












Update Copyright header
2012-02-13T16:11:09+00:00

schu
schu-github@schulog.org

2012-02-13T16:10:24+00:00

5e0de328181c6ddb55a58d4aa7c79271c5298789

Signed-off-by: schu <schu-github@schulog.org>





Signed-off-by: schu <schu-github@schulog.org>







global: Properly use `git__` memory wrappers
2011-10-29T02:02:36+00:00

Vicent Marti
tanoku@gmail.com

2011-10-28T21:51:13+00:00

3286c408eccb18c525ca123383f3ebf5097441bc

Ensure that all memory related functions (malloc, calloc, strdup, free,
etc) are using their respective `git__` wrappers.





Ensure that all memory related functions (malloc, calloc, strdup, free,
etc) are using their respective `git__` wrappers.