kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)

[James Hawkins]

On Thu, Aug 21, 2008 at 2:46 PM, Louis. Lenders
<xerox_xerox2000 at yahoo.co.uk> wrote:
>
>
>>You've handled *a* successful case, but what about the error case?
>
> As i said already in the mail with the patch, it might be *a* case, but this
> is the case
> that most apps will follow as far as i can see. Futhermore, when apps are
> really crashing
> into the other cases, it can be added later on i.m.o. For now they will just
> fall back to the current
> "implementation", returning "not implmented" then, so there will be no
> differnce with current behaviour.
>

That whole paragraphs reads "hack now, fix later", which is definitely
not acceptable.

>
> +    {
> +         lstrcpynW(volumepathname,filename,4);
> +         return TRUE;
> +    }
>
>
>>Also, you're copying 4 bytes of filename into volumepathname.  I don't
>>think you understand what lstrcpyn does.  Imagine this case:
>
> volumepathname = "aaaaaaaa"
> buflen =
>  8
> filename = "C:\\file"
>
> After the call to lstrcpyn:
>
> volumepathname = "C:\\faaaa"
>
>
>
> MSDN says volumepathname was a pointer to an "out" - string, so how would it
> become someting
> like "aaaaaa", or am i overseeing something?
>

Yes you are overseeing something.  I think it would be a good idea if
you read up a bit more on C in your spare time.  I get the feeling you
don't quite have a grasp on the intricacies of the language,
particularly pointers and strings.

-- 
James Hawkins