[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:
>
>addir(".")
> "./childA"
> "./childB"
>addir("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
'no'...
-- PMM