On Sat, Aug 7, 2021 at 11:49 PM Kyle Evans <kev...@freebsd.org> wrote:
> On Sat, Aug 7, 2021 at 10:11 PM Richard Henderson
> <richard.hender...@linaro.org> wrote:
> >
> > On 8/7/21 11:42 AM, Warner Losh wrote:
> > > + path = g_strdup(p);
> > > + if (path == NULL) {
> >
> > Only returns null when the input is null, which you've already
> eliminated.
> >
> > > +static bool find_in_path(char *path, const char *filename, char
> *retpath,
> > > + size_t rpsize)
> > > +{
> > > + const char *d;
> > > +
> > > + while ((d = strsep(&path, ":")) != NULL) {
> > > + if (*d == '\0') {
> > > + d = ".";
> > > + }
> > > + if (snprintf(retpath, rpsize, "%s/%s", d, filename) >=
> (int)rpsize) {
> > > + continue;
> > > + }
> > > + if (is_there((const char *)retpath)) {
> > > + return true;
> > > + }
> > > + }
> > > + return false;
> >
> > Hmm. Fixed size retpath buffer isn't ideal.
> > Any reason not to use g_find_program_in_path?
> >
>
> g_find_program_in_path may work well here, as well...
>
Quite well: 1 file changed, 5 insertions(+), 42 deletions(-) so a nice
reduction in code when the unnecessary stuff is removed. I'll have
that in v2 of the series.
> I note that we don't search the path at all in linux-user/.
> >
>
> IIRC imgact_binmisc will have the resolved path but preserve argv as
> it should have been were it not emulated, so we have to re-evaluate
> the PATH search here because we try to be faithful to the context.
>
I just looked at the imgact_binmisc code, and that's what it does, so
that sounds reasonable to me as well.
Warner
