Re: winmm: prevent NULL dereference in MCI_Close
Jan Zerebecki wrote: If this patch is rejected from inclusion, please tell me why, as I would have to ask anyway. From: Jan Zerebecki [EMAIL PROTECTED] Jan, do you have a specific program that depends on this case ?
Re: Wide-string Functions: Double Casting
David Laight wrote:
On Tue, Aug 08, 2006 at 09:27:23PM +0200, Eric Pouech wrote:
what I don't like is that in order to plug a hole (casting from const
foo* to foo*), we create a bigger hole by allowing to cast from const
foo* to bar* (and the compiler will not give any warning)
if we want to go into this, then I'd rather have _deconst explicitly use
the type:
#define __deconst(v,X)({const X _v = (v); ((X)(int)_v);})
and in the previous example use __deconst(str, char*);
That isn't valid C, you could do:
((const X)(v) - (v), (X)(int)(v))
but that is likely to give a 'computed value not used' warning instead.
What you really don't want to do is allow casts from 'int' to 'foo *'.
After all casting from 'foo *' to 'bar *' is easy.
David
this is supported by gcc...
of course we'd need to define differently the macro for gcc and other
compilers
but casting from foo* to bar* is (in most of the cases) a sign of bad design
A+
Re: ddraw fix for incorrect return value from wined3d take 3.
Hi,
One small comment regarding your patch make sure that you use the same
indentation as the rest of the ddraw code. The ddraw code seems to use 4 spaces
for a tab and I think your editor is configured to use tabs.
Regards,
Roderick Colenbrander
The new test cases crashes under wine but not under
windows. The fix for test cases crash is to initialize
the vertexbuffer to NULL when unsuccessful.
This patch should be used rather then previous one.
thx
Index: dlls/ddraw/direct3d.c
===
RCS file: /home/wine/wine/dlls/ddraw/direct3d.c,v
retrieving revision 1.9
diff -u -r1.9 direct3d.c
--- dlls/ddraw/direct3d.c9 Aug 2006 11:04:37 -1.9
+++ dlls/ddraw/direct3d.c11 Aug 2006 22:47:16 -
@@ -992,8 +992,11 @@
{
ERR((%p) IWineD3DDevice::CreateVertexBuffer failed with hr=%08lx\n,
This, hr);
HeapFree(GetProcessHeap(), 0, object);
+*VertexBuffer = NULL;
if (hr == WINED3DERR_INVALIDCALL)
return DDERR_INVALIDPARAMS;
+if (hr == WINED3DERR_OUTOFVIDEOMEMORY)
+return D3DERR_TOOMANYVERTICES;
else
return hr;
}
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: reasons for not accepting the patch
2006/8/12, Vijay Kiran Kamuju [EMAIL PROTECTED]: [Why wasn't the patch http://www.winehq.org/pipermail/wine-patches/2006-July/029145.html accepted?] I looked at this a couple days ago, and sent this to the patches' author to encourage him to repost it: -- snip --- 1. The patch is missing the filename header, and cannot be applied to the sources by running 'patch'. 2. the patch was posted with the following legal notice: Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. That tells us You may not use this patch. You have to post patches without that. 3. the message did not contain any license information (e.g. Author: Renu Rajput (Tata Inc.) Copyright 2006 Tata Inc License: LGPL. Adding that would help. 4. The message essentially repeated much of the bug report in bugzilla. That's not needed. Just refer to the bug report. Any one of the above four might have been enough to cause the patch to be ignored. Fix them all and you've got a good shot. Two more tips: 5. The bug report in bugzilla does not link to your proposed fix. Often after I post a proposed fix, I add a comment to bugzilla saying something like Patch sent: http://www.winehq.org/pipermail/wine-patches/2006-July/029145.html; Not only does this give another way for people to stumble across and review your patch, it also helps avoid duplication of effort. I had no idea you had sent in a patch for this bug already! 6. Patches that do not get applied need to be resent after a few days. Every time you resend it, you should try to improve it or the test case a bit, and make sure it still applies against current cvs or git. Use the same subject line as before, but append (resend) to the end. Patches are like TCP/IP. There is no ACK when a packet is corrupt, you have to resend after correcting a bit error! --- snip --- Hope that helps. - Dan
Re: Wide-string Functions: Double Casting
Once qualifications are give, how hard it is to take them away, again!
Of course, if one were realising these small inline functions literally as
inline code, one would not add a const qualification for a few lines, only
to take it away again (with great difficulty).
Thus, one would not write:
static WCHAR s[] = {'h','e','l','l','o',0};
LPCWSTR ps1;/* [1] */
LPWSTR ps2;
const WCHAR ch = 'h';
ps1 = s;
ps2 = NULL;
do
{
if (*ps1 == ch)
{
ps2 = (LPWSTR)(uintptr_t)ps1; /* [2] */
break;
}
} while (*ps1++);
if (ps2 != NULL)
*ps2 = 'y';
... when [1] need only be
LPWSTR;
and [2} need only be
ps2 = ps1;
So there might be some argument for specially declaring these few functions
- suitably commented - as taking unqualified string parameters. (The
problem with constifying both input and output pointers is that one might
wish to use the returned pointer to modify the input string.)
However, now that the ANSI/ISO people have given use intptr_t and uintptr_t
(in C99), I don't see what is wrong with, in effect, replacing
ret = (WCHAR *)str;
with
ret = (WCHAR *)(uintptr_t)str;
To avoid touching Wine's configuration files (to add [u]intptr_t for non-C99
systems) the intermediate cast might be have been (unsigned long). Maybe,
(size_t) would have worked, and been more indicative of use(?) unsigned
long should have met the needs of the platforms for which we cater. The
spoiler, apparently, is that it won't work with Win64 type definitions.
Though, I don't know the details.
Anyway, I shall look at fixing the straightforward cast-qual violations,
first, and revisit the controversial issues until the end.
-- Andy.
Missing subtitle in WWN 307
Hi, It's not a big issue but I have noticed that in WWN 311 the article about 'Microsoft WGA Wine' does not have a subject: http://www.winehq.org/?issue=311#Microsoft%20WGA%20%20Wine Currently it reads: ++-+ |Microsoft WGA Wine| Archive | ++-+ That is it is missing the 'subtitle' underneath the gray bar. So it should look something like this: ++-+ |Microsoft WGA Wine| Archive | ++-+ WINE Microsoft WGA Is this an XML parsing bug? -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
Re: winmm: prevent NULL dereference in MCI_Close
On Sat, Aug 12, 2006 at 08:27:24AM +0200, Eric Pouech wrote: do you have a specific program that depends on this case ? Yes, I forgot to mention in last mail, that it fixes a crash in Pacmania 2 ( http://appdb.winehq.org/appview.php?iVersionId=5473 ). I already talked to AJ about this patch on irc and ideally he wants a testcase for this notify behaviour (in addition to demonstrating that passing NULL does not crash). Jan PS: Why does nobody follow the header mail-followup-to? I set it so I don't get Cc-ed because I'm already subscribed. E-Mail is really missing some convenience things... And why does the listserver skip sending me a Mail when I already was Cc-ed?
Re: reasons for not accepting the patch
I think she developed the code while working for the company, unlike me. ;) Then I think she should be doing as you have suggested. Thank you for ur suggestions, Vijay On 8/12/06, Dan Kegel [EMAIL PROTECTED] wrote: 2006/8/12, Vijay Kiran Kamuju [EMAIL PROTECTED]: [Why wasn't the patch http://www.winehq.org/pipermail/wine-patches/2006-July/029145.html accepted?] I looked at this a couple days ago, and sent this to the patches' author to encourage him to repost it: -- snip --- 1. The patch is missing the filename header, and cannot be applied to the sources by running 'patch'. 2. the patch was posted with the following legal notice: Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. That tells us You may not use this patch. You have to post patches without that. 3. the message did not contain any license information (e.g. Author: Renu Rajput (Tata Inc.) Copyright 2006 Tata Inc License: LGPL. Adding that would help. 4. The message essentially repeated much of the bug report in bugzilla. That's not needed. Just refer to the bug report. Any one of the above four might have been enough to cause the patch to be ignored. Fix them all and you've got a good shot. Two more tips: 5. The bug report in bugzilla does not link to your proposed fix. Often after I post a proposed fix, I add a comment to bugzilla saying something like Patch sent: http://www.winehq.org/pipermail/wine-patches/2006-July/029145.html; Not only does this give another way for people to stumble across and review your patch, it also helps avoid duplication of effort. I had no idea you had sent in a patch for this bug already! 6. Patches that do not get applied need to be resent after a few days. Every time you resend it, you should try to improve it or the test case a bit, and make sure it still applies against current cvs or git. Use the same subject line as before, but append (resend) to the end. Patches are like TCP/IP. There is no ACK when a packet is corrupt, you have to resend after correcting a bit error! --- snip --- Hope that helps. - Dan
