summaryrefslogtreecommitdiffstats
path: root/src/util/mesa-sha1.c
Commit message (Collapse)AuthorAgeFilesLines
* util/sha1: harmonize _mesa_sha1_* wrappersGrazvydas Ignotas2017-03-221-6/+0
| | | | | | | | | | Rather than using 3 different ways to wrap _mesa_sha1_*() to SHA1*() functions (a macro, prototype with implementation in .c and an inline function), make all 3 inline functions. Signed-off-by: Grazvydas Ignotas <[email protected]> Reviewed-by: Nicolai Hähnle <[email protected]> Reviewed-by: Emil Velikov <[email protected]>
* util/sha1: drop _mesa_sha1_{update, format} return typeEmil Velikov2017-03-151-5/+2
| | | | | | | | | Unused/unchecked by any of the callers. v2: Fix the glsl cases that have crept in since v1 Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Grazvydas Ignotas <[email protected]>
* util/sha1: rework _mesa_sha1_{init,final}Emil Velikov2017-03-151-29/+5
| | | | | | | | | | | | Rather than having an extra memory allocation [that we currently do not and act accordingly] just make the API take an pointer to a stack allocated instance. This and follow-up steps will effectively make the _mesa_sha1_foo simple define/inlines around their SHA1 counterparts. Signed-off-by: Emil Velikov <[email protected]> Reviewed-by: Grazvydas Ignotas <[email protected]>
* util: import sha1 implementation from OpenBSD17.0-branchpointEmil Velikov2017-01-181-241/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment we support 5+ different implementations each with varying amount of bugs - from thread safely problems [1], to outright broken implementation(s) [2] In order to accommodate these we have 150+ lines of configure script and extra two configure toggles. Whist an actual implementation being ~200loc and our current compat wrapping ~250. Let's not forget that different people use different code paths, thus effectively makes it harder to test and debug since the default implementation is automatically detected. To minimise all these lovely experiences, import the "100% Public Domain" OpenBSD sha1 implementation. Clearly document any changes needed to get building correctly, since many/most of those can be upstreamed making future syncs easier. As an added bonus this will avoid all the 'fun' experiences trying to integrate it with the Android and SCons builds. v2: Manually expand __BEGIN_DECLS/__END_DECLS and document (Tapani). Furthermore it seems that some games (or surrounding runtime) static link against OpenSSL resulting in conflicts. For more information see the discussion thread [3] Bugzilla [1]: https://bugs.freedesktop.org/show_bug.cgi?id=94904 Bugzilla [2]: https://bugs.freedesktop.org/show_bug.cgi?id=97967 [3] https://lists.freedesktop.org/archives/mesa-dev/2017-January/140748.html Cc: Mark Janes <[email protected]> Cc: Vinson Lee <[email protected]> Cc: Tapani Pälli <[email protected]> Cc: Jonathan Gray <[email protected]> Tested-by: Jonathan Gray <[email protected]> Signed-off-by: Emil Velikov <[email protected]> Acked-by: Tapani Pälli <[email protected]> (v1) Acked-by: Jason Ekstrand <[email protected]> (v1)
* util: Fix warning of invalid return valueChad Versace2016-04-151-1/+2
| | | | | | _mesa_libgcrypt_init() returns NULL, but its return type is void. Reviewed-by: Mark Janes <[email protected]>
* util: Fix race condition on libgcrypt initializationMark Janes2016-04-151-8/+11
| | | | | | | | | | | | | Fixes intermittent Vulkan CTS failures within the test groups: dEQP-VK.api.object_management.multithreaded_per_thread_device dEQP-VK.api.object_management.multithreaded_per_thread_resources dEQP-VK.api.object_management.multithreaded_shared_resources Signed-off-by: Mark Janes <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94904 Reviewed-by: Edward O'Callaghan <[email protected]> Reviewed-by: Jason Ekstrand <[email protected]>
* util: make mesa-sha1.c completely empty when there are no SHA1 implsIlia Mirkin2015-09-071-2/+2
| | | | | | | | | | | My earlier attempt to fix this missed the fact that there was a #else clause that assumes that you have openssh. This moves the whole thing under #ifdef HAVE_SHA1 which should avoid this issue. Fixes: 13bfa5201 (util: always include sha1 into the build) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91898 Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* util: always include sha1 into the buildIlia Mirkin2015-09-061-0/+4
| | | | | | | | | SHA1 is now used in all builds when HAVE_SHA1 is defined. Adjust src to do the same thing, rather than predicating on shader cache. Fixes: 04e201d0c02 ("mesa: change 'SHADER_SUBST' facility to work with env variables") Signed-off-by: Ilia Mirkin <[email protected]> Reviewed-by: Dave Airlie <[email protected]>
* Rename sha1.c and sha1.h to mesa-sha1.c and mesa-sha1.hCarl Worth2015-01-191-0/+316
The filename of sha1.h was conflicting with the system-provided sha1.h, (and in some confiurations, our sha1.c was unsuccessfully attemping to include "sha1.h" and <sha1.h> as two different files). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88523