Open mizuno-as opened 4 years ago
I've same issue on my Gentoo box after switching to GCC 10.1.
Can I try working on the first 2 warnings shown in the build logs? The rest of the errors/warnings regarding the multiple definitions seem to be due to the inclusion of the header file(s) multiple times, in different files, this could be fixed by using preprocessor directives.
Looking forward to working on the issue.
Thanks
The multiple symbol definition issues are fixed by https://github.com/ggreer/the_silver_searcher/pull/1377 (21eaa1c4160b868b0c5bbf59da17974429f30055)
@aswild, thank you for cross-referencing these issues :-) @rishitc, how is your work progressing? The Silver Searcher has been scheduled for autoremoval (Bug #957798) in Debian as a result of this issue. Is it still the case that these need to be fixed?:
src/lang.c: In function 'combine_file_extensions':
src/lang.c:198:13: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
198 | strncpy(pos, ext, strlen(ext));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC src/decompress.o
src/decompress.c: In function 'decompress_zlib':
src/decompress.c:52:22: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
52 | stream.next_in = (Bytef *)buf;
(some of my packages depend on silversearcher-ag and will also be removed). CCing @mizuno-as
Hi,
I have been working on the issue in the background.
@sten0 The warning you mentioned is still present while running the ./build.sh
command.
I tried building it on GCC version 9.3.0 (Ubuntu 9.3.0-10ubuntu2) and it still gives the same warnings, it doesn't stop the compilation though as -Werror
flag does not seem to be set.
I am still working on fixing the warning as a clean build output is a priority.
@sten0 I'm going to add a CFLAGS to the silversearcher-ag package to get around it. but I'd like to see a correction on upstream, if possible.
I opened https://github.com/ggreer/the_silver_searcher/pull/1398 to all compile warnings seen on Arch Linux with GCC 10 (-Wstringop-truncation in lang.c and -Wcast-qual in decompress.c)
I don't have a Debian box with GCC10, but the warnings on Arch were the same as in https://github.com/ggreer/the_silver_searcher/issues/1378#issuecomment-665253277
I think the fix made by @aswild in #1398, is correct for the warning:
src/decompress.c: In function 'decompress_zlib':
src/decompress.c:52:22: warning: cast discards 'const' qualifier from pointer target type [-Wcast-qual]
52 | stream.next_in = (Bytef *)buf;
At first, I thought that const
needed to be removed for the variable buf
as the link that the original author had referred to in a comment, in the decompress.c
file, uses a variable exactly like buf
called in
, which has the type: unsigned char (unsigned is by default anyway) but it is not marked const
in that code.
Here is original comment form the decompress.c
file, I am referring to:
/* Code in decompress_zlib from
*
* https://raw.github.com/madler/zlib/master/examples/zpipe.c
*
* zpipe.c: example of proper use of zlib's inflate() and deflate()
* Not copyrighted -- provided to the public domain
* Version 1.4 11 December 2005 Mark Adler
*/
Not sure if the correction made by @aswild is correct for the other warning:
src/lang.c: In function 'combine_file_extensions':
src/lang.c:198:13: warning: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
198 | strncpy(pos, ext, strlen(ext));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC src/decompress.o
As replacing strncpy
with memcpy
is not a recommended practice as strncpy
checks for the NULL terminating character while copying, so it is safer as compared to using memcpy
. Also, strncpy
pads the remaining/extra memory block in the destination with NULL characters.
Also, as you're using memcpy
, buffer overflows are still possible and now might be hidden from the compile-time checks. I would recommend you try running Valgrind to verify if there are any memory errors/buffer overflows.
FWIW, the strncpy->memcpy change makes the code behave identically as it does now (since the *exts array is zero-initialized), but I agree it isn't ideal. strncpy where n==strlen(src) is just as susceptible to buffer overflows in dest as memcpy. I ran the test suite against AddressSanitizer (compile with -fsanitize=address) and didn't get any overflows flagged, just a handful of inconsequential leaks.
In my personal fork I refactored this whole area to add features (like matching full filenames e.g. Makefile or CMakeLists.txt), but that deep of refactoring is probably beyond the scope of fixing compile warnings here.
I had thought that the SINGLE_EXT_LEN math would work out such that there couldn't be overflow, but I see now that's wrong - there's no actual checking that the size of any extension in langs is within SINGLE_EXT_LEN.
What we really need to do is some math to calculate the remaining space in exts and use that as the max length of the copy. I'll update my PR accordingly.
I got inspired to write some nontrivial C tonight, so I refactored the entirety of make_lang_regex and combine_file_extensions (removing the latter). This should remove the potential overflow vulnerabilities, and IMO makes the code easier to follow, but the UX remains the same.
@rishitc @ggreer I'd appreciate any review comments if/when you get a chance.
Thanks @mizuno-as :-) I'm relieved to hear you have a contingency plan in place. 27 days to autoremoval of about nine packages.
Will anyone have time to review & merge aswild's work before then?
I'm trying to build with GCC 11 and, not surprisingly, I'm getting the issues above and many more like
warning: implicit declaration of function 'vasprintf'
error: unknown type name 'cookie_read_function_t'
undefined reference to symbol 'pthread_create'
I'd love to see these issues being fixed and released. In the mean time, I found is this workaround:
make CFLAGS="-fcommon -D_GNU_SOURCE -lpthread"
@cassioneri - those CFLAGS
worked for me on alpine 3.13. Thank you!
Do you plan a new release fixing all this ?
I installed GCC-10 from experimental in Debian sid environment. In this environment, the build has failed with linker error. The cause is that the
-fno-common
option is the default in GCC-10. The workaround is to addCFLAGS='-fcommon'
to configure.FYI: http://gcc.gnu.org/gcc-10/porting_to.html
How to reproduce.