Thanks for confirming that this solved the problem! It seems explicit_bzero is patched in gnulib now, so this shouldn't be a problem going foward, so I'll think about adding a CI/CD build with -std=c99 to test regressions in this area. I wonder if -std=c89 works too... we have a CI/CD build using 'tcc' instead of 'gcc' so I think it should work.
However, generally I would recommend against using -std=c99 for building libtasn1 though, it may pull in unnecessary replacement code from gnulib to re-implement some -std=gnu99 functionality. The replacement code may be more limited than what your system supports. I didn't verify that this actually happens, but it is a possibility generally. /Simon Vincent Fortier <th0...@gmail.com> writes: > Thnx, the tip paid off, switching to -std=gnu99 solved the issue... > Help much appreciated! > > Cheers! > > - vin > > Le dim. 27 nov. 2022, à 06 h 13, Simon Josefsson <si...@josefsson.org> a > écrit : >> >> 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