[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] [PATCH] Further simplify dodir/addir/addfold in uip/fo

From: Peter Maydell
Subject: Re: [Nmh-workers] [PATCH] Further simplify dodir/addir/addfold in uip/folder.c
Date: Tue, 05 Aug 2008 20:27:06 +0100

Eric Gillespie wrote:
>Peter Maydell writes:
>> (I wasn't completely convinced about the way the first patch
>> drops the handling in addir() of names starting "./", but I couldn't
>> get it to misbehave, and I don't think it's actually possible to
>> get such a name except when the name is the literal ".". Can
>> you confirm that?)
>Sure.  The old code was unconditionally overwriting name's
>terminating null byte with "/" (without the bounds-checking used
>later in the function; I guess no one has 8K (BUFSIZ) long folder
>paths anyway ;-> but then why check later?) and then latter
>appending child folder names to that, so:
>  "./childA"
>  "./childB"
>  "childB/childC"
>So, nothing wrong with the second call, but the call that starts
>it all (addir(".")) causes folder to prefix every folder with
>"./".  The old code solved this with yet another pointer into
>this buffer (I remember at least 3 of these).  Instead, I
>conditionalized the prefix.

Yes. The question is whether it's possible for anything to call
addir("./something") -- which the old code would treat like
addir("something") but yours would not. I *think* the answer is

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]