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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers