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

[James Hawkins]

On Thu, Aug 21, 2008 at 3:59 PM, Louis. Lenders
<xerox_xerox2000 at yahoo.co.uk> wrote:
>
>
> ----- Original Message ----
> From: James Hawkins <truiken at gmail.com>
> To: Louis. Lenders <xerox_xerox2000 at yahoo.co.uk>
> Cc: wine-devel at winehq.org
> Sent: Thursday, 21 August, 2008 3:55:07 PM
> Subject: Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try
> 4)
>
>
>
>>That whole paragraphs reads "hack now, fix later", which is definitely
>>not acceptable.
>
> Well, I would call it a "semi-stub", there's more of them scattered all over
> the wine-source. But  if opinions are it's too hackish, that's fine with me,
> I was only trying to help a user to get an app running
>
>>
>> +    {
>> +        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.
>
> What I meant is, why would an app set volumepathname to "aaaaaa", as it's
> the pointer where it expects to find the volumepoint, so on windows  this
> would be filled  by kernel32.dll, not by the app. Maybe you mean this could
> be the case after a second call to GetVolumePathName? Anyway, this is not
> the place to discuss a C-language course so I'll reread the docs. Thanks for
> the comments anyway.
>

That's not the point, and you're missing the real problem which was
stated in my first email.  Your call to lstrcpyn is wrong, and I was
just showing you what will go wrong.  In no circumstances will that
call to lstrcpyn turn out correctly, even if the input buffer is
initialized to all zeros.

-- 
James Hawkins