src/hash.c


Log

Author Commit Date CI Message
lhchavez 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.
Edward Thomson 253a873b 2020-04-05T16:33:54 hash: use GIT_ASSERT
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Patrick Steinhardt 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.
Edward Thomson 359fc2d2 2013-01-08T17:07:25 update copyrights
Edward Thomson 603bee07 2012-11-12T19:22:49 Remove git_hash_ctx_new - callers now _ctx_init()
Edward Thomson d6fb0924 2012-11-05T12:37:15 Win32 CryptoAPI and CNG support for SHA1
schu 5e0de328 2012-02-13T17:10:24 Update Copyright header Signed-off-by: schu <schu-github@schulog.org>
Vicent Marti 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.
Vicent Marti 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.
Vicent Marti 17d52304 2011-07-01T17:26:23 build: Simplify build structure This will make libgit2 more suitable for embedding.
Ramsay Jones 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>
Ramsay Jones 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>
Andreas Ericsson 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>
Ramsay Jones 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>
Shawn O. Pearce 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>
Ramsay Jones 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>