On Thu, Aug 21, 2008 at 3:59 PM, Louis. Lenders <[EMAIL PROTECTED]> wrote: > > > ----- Original Message ---- > From: James Hawkins <[EMAIL PROTECTED]> > To: Louis. Lenders <[EMAIL PROTECTED]> > Cc: [email protected] > 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
