Hi. We got a bug report about a build failure (see below), and I'm wondering:
1) Does gnulib support building with gcc -std=c99? I think we should, but it could have documented missing functionality or breakage. 2) It seems explicit_bzero.c in gnulib fall backs to using 'asm' for GCC, which isn't working in non-GNU modes of gcc. Further wondering: 1) The reason for having explicit_bzero is read_file, which needs it for reading sensitive files, a feature we don't use. Uncoupling this unnecessary dependency would have been nice. 2) Is there no other way to implement explicit_bzero without 'asm'? There is a another fallback code using volatile pointers, but I'm not sure it really has the same semantics. 3) Is there a way to detect if the compiler supports 'asm'? The current test 'defined __GNUC__ && !defined __clang__' is what is really failing here. 3) Is the idiom of using separate functions bzero() vs explicit_bzero() to avoid security-problematic compiler optimization still a good one? 1) If yes, I think we should have read_sensitive_file() rather than extending read_file() with a flag for this purpose. 2) If no, what is the better idiom to use here instead of explicit_bzero? Other thoughts? /Simon Simon Josefsson via Discussion list for GNU Libtasn1 <help-libta...@gnu.org> writes: > Vincent Fortier <th0...@gmail.com> writes: > >> While preparing a gnutls update I ended-up updating libtasn1 from >> 4.16. Going to 4.17 works but anything after that fails with: > > Thanks for the report! I can reproduce this using: > > ./configure ac_cv_func_explicit_bzero=no CPPFLAGS="-std=c99" > > In other words, the problem is due to a combination of a platform > without explicit_bzero and forcing GCC into C99 mode where it doesn't > support 'asm', so it is not possible to implement 'explicit_bzero'. Why > do you hard code -std=c99? Try just removing that. Or use -std=gnu99' > to allow GCC to use 'asm'. > > Analysing further, the 'explicit_bzero' function is only used by > 'read_file' in a mode that we never use (for reading sensitive files), > so it is never needed by libtasn1. This is not ideal, but I'm not sure > what a maintainable solution is. > > /Simon >
signature.asc
Description: PGP signature