* src/mktemp.c: When --suffix was supply in cmdline, the template
points to the meraged buffer(dest_name). As X is counted from
template which not contains suffix, So the output should be cut.
Signed-off-by: lvgenggeng
---
src/mktemp.c | 9 +++--
1 file changed, 7 insertions(+), 2
Testing the current coreutils git master:
On a Debian 12 system, in which I have not installed a French UTF-8 locale,
I see a test failure of tests/misc/join-utf8.
The essential lines from test-suite.log:
+ test set = set
+ LC_ALL=none
../tests/misc/join-utf8.sh: line 24: warning: setlocale:
On 26/02/2024 18:06, Andreas Schwab wrote:
On Feb 26 2024, Pádraig Brady wrote:
https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
It's still bad as it adds a hidden dependency that is invisible to rpm.
Right. In practice though since coreutils also links libcrypto
for
On 2024-02-26 06:12, Pádraig Brady wrote:
On 26/02/2024 06:44, Yann Collet wrote:
* xxhash128 is not a cryptographic hash function, so it doesn't
attempt tobe random.
Just a correction : xxh128 does try to be random. And quite hardly: a
significant amount of development is spent on
On Feb 26 2024, Pádraig Brady wrote:
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
It's still bad as it adds a hidden dependency that is invisible to rpm.
Also, the regexp in the sed command contains unquoted uses of '.' that
are supposed to be matched literally.
--
On 26/02/2024 17:39, Bruno Haible wrote:
Pádraig Brady wrote:
+ void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
That only works if libopenssl-devel is installed.
Good spot.
I'd already pushed a fix for this at:
Pádraig Brady wrote:
> >> + void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
> >
> > That only works if libopenssl-devel is installed.
>
> Good spot.
> I'd already pushed a fix for this at:
> https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=3bbdb3938
Does this work
On 26/02/2024 17:11, Andreas Schwab wrote:
On Feb 25 2024, Paul Eggert wrote:
+/* Dynamically link the crypto library, if it needs linking. */
+static void
+link_libcrypto (void)
+{
+#if DLOPEN_LIBCRYPTO && HAVE_OPENSSL_MD5
+ void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
On 26/02/2024 06:25, Paul Eggert wrote:
On 2023-10-09 06:48, Pádraig Brady wrote:
An incremental patch attached to use xxhash128 (0.8.2)
shows a good improvement (note avx2 being used on this cpu):
xxhash128 is not a cryptographic hash function, so it doesn't attempt to
be random. Of course
On Feb 25 2024, Paul Eggert wrote:
> +/* Dynamically link the crypto library, if it needs linking. */
> +static void
> +link_libcrypto (void)
> +{
> +#if DLOPEN_LIBCRYPTO && HAVE_OPENSSL_MD5
> + void *handle = dlopen ("libcrypto.so", RTLD_LAZY | RTLD_GLOBAL);
That only works if
* xxhash128 is not a cryptographic hash function, so it doesn't attempt to
be random.
Just a correction : xxh128 does try to be random. And quite hardly: a
significant amount of development is spent on ensuring this property.
It’s even tested with PractRand, and it could be used as a good
On 26/02/2024 06:44, Yann Collet wrote:
* xxhash128 is not a cryptographic hash function, so it doesn't attempt tobe
random.
Just a correction : xxh128 does try to be random. And quite hardly: a
significant amount of development is spent on ensuring this property.
It’s even tested with
On 2023-10-09 06:48, Pádraig Brady wrote:
An incremental patch attached to use xxhash128 (0.8.2)
shows a good improvement (note avx2 being used on this cpu):
xxhash128 is not a cryptographic hash function, so it doesn't attempt to
be random. Of course most people won't care - it's random
13 matches
Mail list logo
