"qfile /bin/bash" doesn't output anything on Gentoo/FreeBSD. qfile.c assume basename(path) always return a pointer to some part of path. But this is not always true. We get wrong "dirname_len" and so qfile failed to find the package. Reproducible: Always Steps to Reproduce: 1. emerge portage-utils on Gentoo/FreeBSD 2. qfile /bin/bash Actual Results: no output Expected Results: qfile should print "app-shells/bash (/bin/bash)"
Created attachment 235227 [details, diff] patch to fix qfile.c wrong dirname_len calculation With applying this patch, "qfile /bin/bash" output adequate result.
TGL, I think he is commenting on some code of yours. Would you mind reviewing this and suggesting what should be done. Thanks in advance. Naohiro, When you file a bug, it's best to include the exact versions you are talking about. I'll assume you tested with current ~arch.
the code was specifically written to avoid the overhead of string calls. i cant see why bsd would operate differently since i cant see how it would be better for performance, and because the spec specifically allows the behavior. perhaps we simply implement our own local basename to avoid this moronic C library behavior. the glibc specific one looks nice: char *basename (const char *filename) { char *p = strrchr (filename, '/'); return p ? p + 1 : (char *) filename; }
Created attachment 238967 [details, diff] patch to use local "basename" function. SpanKY I agree. Implementing our own one would be better if we can. I've wrote this patch and this worked for both Linux and FreeBSD. (checked by "FEATURES=test emerge portage-utils" on Linux, and run "qfile /bin/bash" on FreeBSD)
i dont want to go that way as people will often not notice "mybasename" and will continue to use "basename". as such, ive created a local basename() and constified all the callers in the tree. cvs should work now.
