----- Original Message ---- From: James Hawkins truiken@gmail.com To: Louis. Lenders xerox_xerox2000@yahoo.co.uk Cc: wine-devel@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.
Send instant messages to your online friends http://uk.messenger.yahoo.com
On Thu, Aug 21, 2008 at 3:59 PM, Louis. Lenders xerox_xerox2000@yahoo.co.uk wrote:
----- Original Message ---- From: James Hawkins truiken@gmail.com To: Louis. Lenders xerox_xerox2000@yahoo.co.uk Cc: wine-devel@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 -
Louis. Lenders