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

[Peter Maydell]

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