|
0e53e55d
|
2022-01-22T14:18:48
|
|
hash: introduce git_hash_fmt
A simple hash-to-hexadigit formatter.
|
|
|
f0e693b1
|
2021-09-07T17:53:49
|
|
str: introduce `git_str` for internal, `git_buf` is external
libgit2 has two distinct requirements that were previously solved by
`git_buf`. We require:
1. A general purpose string class that provides a number of utility APIs
for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
can take ownership of.
By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.
Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class. The name also
is an homage to Junio Hamano ("gitstr").
The public API remains `git_buf`, and has a much smaller footprint. It
is generally only used as an "out" param with strict requirements that
follow the documentation. (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)
Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.
|
|
|
31ecaca2
|
2021-09-30T08:11:40
|
|
hash: hash functions operate on byte arrays not git_oids
Separate the concerns of the hash functions from the git_oid functions.
The git_oid structure will need to understand either SHA1 or SHA256; the
hash functions should only deal with the appropriate one of these.
|
|
|
2a713da1
|
2021-09-29T21:31:17
|
|
hash: accept the algorithm in inputs
|
|
|
3fff5970
|
2021-09-29T21:02:38
|
|
hash: don't abbreviate algorithm
|
|
40f3702c
|
2021-08-25T11:36:06
|
|
c90/c99: name the unnamed union in git_hash_ctx
|
|
5db304f0
|
2020-11-27T06:17:57
|
|
Fix the non-debug build in Groovy Gorilla (gcc 10.2)
The release build has been failing with the following error:
```shell
FAILED: src/CMakeFiles/git2internal.dir/hash.c.o
/usr/bin/cc -DHAVE_QSORT_R_GNU -DSHA1DC_CUSTOM_INCLUDE_SHA1_C=\"common.h\" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C=\"common.h\" -DSHA1DC_NO_STANDARD_INCLUDES=1 -D_FILE_OFFSET_BITS=64 -Isrc -I../src -I../include -I../deps/pcre -I../deps/http-parser -D_GNU_SOURCE -fsanitize=thread -fno-optimize-sibling-calls -fno-omit-frame-pointer -Werror -Wall -Wextra -fvisibility=
hidden -fPIC -Wno-documentation-deprecated-sync -Wno-missing-field-initializers -Wstrict-aliasing -Wstrict-prototypes -Wdeclaration-after-statement -Wshift-count-overflow -Wunused-const-variable -Wunused-function -Wint-conversion -Wformat -Wformat-security -Wmissing-declarations -g -D_DEBUG -O0 -std=gnu90 -MD -MT src/CMakeFiles/git2internal.dir/hash.c.o -MF s
rc/CMakeFiles/git2internal.dir/hash.c.o.d -o src/CMakeFiles/git2internal.dir/hash.c.o -c ../src/hash.c
../src/hash.c: In function ‘git_hash_init’:
../src/hash.c:47:1: error: control reaches end of non-void function [-Werror=return-type]
47 | }
| ^
../src/hash.c: In function ‘git_hash_update’:
../src/hash.c:58:1: error: control reaches end of non-void function [-Werror=return-type]
58 | }
| ^
../src/hash.c: In function ‘git_hash_final’:
../src/hash.c:68:1: error: control reaches end of non-void function [-Werror=return-type]
68 | }
| ^
../src/hash.c: At top level:
cc1: note: unrecognized command-line option ‘-Wno-documentation-deprecated-sync’ may have been intended to silence earlier diagnostics
cc1: all warnings being treated as errors
[11/533] Building C object src/CMakeFiles/git2internal.dir/odb_pack.c.o
ninja: build stopped: subcommand failed.
```
The compiler _should_ be able to figure out that there is no way to reach the
end of the non-void function since `GIT_ASSERT(0)` expands to either `assert()`
or an unconditional `return -1;` (after doing constant folding and stuff,
depending on the debug level). But it's not doing so at the moment, so let's
help it.
|
|
|
253a873b
|
2020-04-05T16:33:54
|
|
hash: use GIT_ASSERT
|
|
7fd3f32b
|
2019-06-27T13:54:55
|
|
hash: fix missing error return on production builds
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.
|
|
|
b7187ed7
|
2019-02-22T14:38:31
|
|
hash: add ability to distinguish algorithms
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.
|
|
|
8832172e
|
2019-02-22T14:32:40
|
|
hash: move SHA1 implementations to its own hashing context
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.
|
|
|
d46d3b53
|
2019-04-05T10:59:46
|
|
hash: split into generic and SHA1-specific interface
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.
|
|
|
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.
|
|
|
359fc2d2
|
2013-01-08T17:07:25
|
|
update copyrights
|
|
|
d6fb0924
|
2012-11-05T12:37:15
|
|
Win32 CryptoAPI and CNG support for SHA1
|
|
603bee07
|
2012-11-12T19:22:49
|
|
Remove git_hash_ctx_new - callers now _ctx_init()
|
|
5e0de328
|
2012-02-13T17:10:24
|
|
Update Copyright header
Signed-off-by: schu <schu-github@schulog.org>
|
|
3286c408
|
2011-10-28T14:51:13
|
|
global: Properly use `git__` memory wrappers
Ensure that all memory related functions (malloc, calloc, strdup, free,
etc) are using their respective `git__` wrappers.
|
|
|
bb742ede
|
2011-09-19T01:54:32
|
|
Cleanup legal data
1. The license header is technically not valid if it doesn't have a
copyright signature.
2. The COPYING file has been updated with the different licenses used in
the project.
3. The full GPLv2 header in each file annoys me.
|
|
|
17d52304
|
2011-07-01T17:26:23
|
|
build: Simplify build structure
This will make libgit2 more suitable for embedding.
|
|
d03f5675
|
2010-06-04T18:20:31
|
|
Remove the sha1.h header file and inline the content into hash.c
Given that the sha1.h header file should never be included into
any other file, since it represents an implementation detail of
hash.c, we remove the header and inline it's content.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
|
|
|
38c513b9
|
2010-04-28T19:07:14
|
|
Add support to enable the library to use OpenSSL SHA1 functions
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
|
|
5dddf7c8
|
2010-04-14T20:41:57
|
|
Add block-sha1 in favour of the mozilla routines
Since block-sha1 from git.git has such excellent performance, we
can also get rid of the openssl dependency. It's rather simple
to add it back later as an optional extra, but we really needn't
bother to pull in the entire ssl library and have to deal with
linking issues now that we have the portable and, performance-wise,
truly excellent block-sha1 code to fall back on.
Since this requires a slight revamp of the build rules anyway, we
take the opportunity to fix including EXTRA_OBJS in the final build
as well.
The block-sha1 code was originally implemented for git.git by
Linus Torvalds <torvalds@linux-foundation.org> and was later
polished by Nicolas Pitre <nico@cam.org>.
Signed-off-by: Andreas Ericsson <ae@op5.se>
|
|
|
1906f236
|
2009-02-26T20:37:20
|
|
Add built-in (Mozilla) SHA1 routines
Paul agreed to the GCC-exception license by email:
|
| From: Paul Kocher <paul@cryptography.com>
| Date: Sun, 15 Mar 2009 11:37:23 -0700
| Subject: Re: Adding Mozilla SHA1 implementation to libgit2
|
| Yes - that's fine.
|
| At 01:56 AM 3/5/2009, Andreas Ericsson wrote:
| > Hi Paul. We spoke earlier about this, if you remember?
| > We'd like to add the GCC-exception to the GPL license
| > for these files.
Signed-off-by: Paul Kocher <paul@cryptography.com>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
64a47c01
|
2008-12-30T23:21:36
|
|
Wrap malloc and friends and report out of memory as GIT_ENOMEM
We now forbid direct use of malloc, strdup or calloc within the
library and instead use wrapper functions git__malloc, etc. to
invoke the underlying library malloc and set git_errno to a no
memory error code if the allocation fails.
In the future once we have pack objects in memory we are likely
to enhance these routines with garbage collection logic to purge
cached pack data when allocations fail. Because the size of the
function will grow somewhat large, we don't want to mark them for
inline as gcc tends to aggressively inline, creating larger than
expected executables.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
|
007e0753
|
2008-12-27T18:58:25
|
|
Add some routines for SHA1 hash computation
[sp: Changed signature for output to use git_oid, and added
a test case to verify an allocated git_hash_ctx can be
reinitialized and reused.]
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|