Sujet : Re: why does bsearch segfault on custom strcmp when qsort works fine?
De : already5chosen (at) *nospam* yahoo.com (Michael S)
Groupes : comp.lang.cDate : 15. Aug 2024, 13:10:09
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20240815151009.0000241f@yahoo.com>
References : 1 2
User-Agent : Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
On Thu, 15 Aug 2024 10:06:53 +0100
Richard Harnden <
richard.nospam@gmail.invalid> wrote:
On 15/08/2024 06:56, Mark Summerfield wrote:
I have a program (complete source at the end) which correctly
outputs this:
["charlie" "foxtrot" "oscar" "echo" "alpha" "golf" "tango" "delta"
"bravo"] ["alpha" "bravo" "charlie" "delta" "echo" "foxtrot" "golf"
"oscar" "tango"] check_array OK
check_index_found true OK
check_index_found false OK
However, if you uncomment the "//#define BUG" line, the output (in
gdb) is this:
(gdb) run
Starting program: /home/mark/tmp/mycmpstr/mycmpstr
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1". ["charlie" "foxtrot"
"oscar" "echo" "alpha" "golf" "tango" "delta" "bravo"] ["alpha"
"bravo" "charlie" "delta" "echo" "foxtrot" "golf" "oscar" "tango"]
check_array OK
Program received signal SIGSEGV, Segmentation fault.
__strcmp_avx2 () at ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
283 ../sysdeps/x86_64/multiarch/strcmp-avx2.S: No such file
or directory. (gdb) bt
#0 __strcmp_avx2 () at
../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 #1
0x00005555555553e0 in mystrcmp (s=0x555555556030, t=0x7fffffffde10)
at mycmpstr.c:50 #2 0x00007ffff7e0a53c in __GI_bsearch
(__key=0x555555556030, __base=0x7fffffffddf0, __nmemb=<optimized
out>, __size=8, __compar=0x5555555553b7 <mystrcmp>) at
out>../bits/stdlib-bsearch.h:33 #3 0x0000555555555317 in main ()
out>at mycmpstr.c:30
The difference is that without BUG defined I use my own binary
search, but with BUG defined I use bsearch.
[...]
int mystrcmp(const void* s, const void* t) {
return strcmp(*(const char**)s, *(const char**)t);
You don't need to cast void*s, change that to:
return strcmp(s, t);
}
No, his mystrcmp() is correct. The bugs are elsewhere, as explained by
Ike Naar.
Unfortunately, unlike the previous case with attempt to modify string
literals, these bugs are less likely to lead to interesting discussion.