Hello,
The Classic McEliece implementation assumes that unaligned access for
64-bit and 32-bit are OK. It is not the case for some architectures.
Here is a patch to point out the issue. Better patch is welcome.
--
diff --git a/cipher/mceliece6688128f.c b/cipher/mceliece6688128f.c
index 63d20
Hi Team,This is my first time contribution in libgcrypt. Here I have attached the DCO file as mentioned in policy.Thank you,Simit Ghane
DCO.asc
Description: Binary data
___
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/
Hi Team,This is my first time contribution in libgcrypt. Here I have attached the DCO file as mentioned in policy.Thank you,Simit Ghane___
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
On Mon, 6 May 2024 17:07, simit.ghane said:
> Characters like '-O2' or '-Ofast' will be replaced by '-O1' when
> compiling cipher and random in the filesystem paths as well if
> they happen to contain '-O2' or '-Ofast
Indeed that will be a problem.
> Fix this by adding blank spaces before and af
Characters like '-O2' or '-Ofast' will be replaced by '-O1' when
compiling cipher and random in the filesystem paths as well if
they happen to contain '-O2' or '-Ofast
If we are cross compiling libgcrypt and sysroot contains such
characters, we would
get compile errors because the sysroot path has