May 16 2019
Sep 21 2017
Closing due to compiler error.
Aug 1 2017
No, it's not. It still misses "-O" entirely.
Jul 24 2017
The fixed sed expression still does not work correctly; it misses the plain "-O" form of the option. As per gcc docs, -O is the same as -O1, and clang accepts it (and the build falls over with it) even though it does not document it at all.
The warning is just a warning, so no problem. The pragma even indicates the compiler for which it is intended.
Jul 6 2017
I did some experimenting and clang SIGILL does not trigger with commonly used, but non-conforming, variable-length object with "struct hack", as below:
Jul 5 2017
With an integer overflow.
This is a standard dynamic sized array:
Sorry, this is a standard C feature and the only way to have dynamic sized arrays. CLANG simply does not get this pattern right. Grep for pgut001's very comments on such ill behaving compilers (including gcc).
At a meta level, I really think that writing more conservative code that enables compilers to do a better job checking for safety is a good idea. The tricks we do with structs are premature optimization from a time when compilers were dumb as a doornail.
Maybe casting to a void* helps to disable the check in the compiler.
I can replicate the issue on my system.
It is not the line 681, actually.
Jul 4 2017
I think that the problem is in your usage with your tool. Please have a look at md_open function in cipher/md.c.
This bug is not the one in libgcrypt, but in the compiler.
Same argument can apply to MD5. See T3249: sha256.c:265:3: runtime error: unsigned integer overflow: 4084723048 + 1633837952 cannot be represented in type 'unsigned int' of SHA2.
See T3248: mpiutil.c:501:37: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long' for unsigned integer overflow.
It is intentionally used.
And in the C programming language, it is defined that unsigned integer never overflows (it is computed as modulo 2).
Mar 30 2017
Nov 8 2012
Fixed in git for gnupg 1.4.13, Libgcrypt 1.5.1 and Libgcrypt 1.6.0.
The reason why I was not able to replicate this bug was that
I didn't use -std=c99 with gcc >= 4.3.
Aug 9 2012
See my comments for T1406. It is clearly a clang bug.