Summary: | app-portage/portage-utils: qfile does not work on *BSD | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Naohiro Aota <naota> |
Component: | Tools | Assignee: | Portage Utils Team <portage-utils> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | tom.gl |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | FreeBSD | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
patch to fix qfile.c wrong dirname_len calculation
patch to use local "basename" function. |
Description
Naohiro Aota
![]() 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. |