On Sat, 15 Dec 2012, Alexandre Julliard wrote:
Current snapshots of GCC 4.8.0 issue a warning about some of the
new code in windowscodecs/pngformat.c:
pngformat.c: In function 'PngDecoder_Frame_GetColorContexts':
pngformat.c:882:5: warning: passing argument 5 of 'ppng_get_iCCP' from
On Thu, 8 Mar 2012, Gerald Pfeifer wrote:
I noticed we return in this case, without initializing this variable.
Visual inspection indicates we do not seem to access the variable in
this error case, but a) better safe than sorry, and b) GCC 4.8 currently
warns about it.
I generally don't think
On Thu, 8 Mar 2012, Jacek Caban wrote:
I noticed we return in this case, without initializing this variable.
Visual inspection indicates we do not seem to access the variable in
this error case, but a) better safe than sorry, and b) GCC 4.8 currently
warns about it.
I generally don't think
Hi James,
On Thu, 13 May 2010, Gerald Pfeifer wrote:
Would you feel more comfortable leaving the documentation as is and
me just suggesting the following?
if(strchrW(str_flags,'I'))
hr = do_ocx_reg(hm, TRUE);
to replace
hr = do_ocx_reg(hm, TRUE);
?
Or would you
On Thu, 8 Sep 2011, Alexandre Julliard wrote:
It's still wrong, the parameter is used inside the #ifdef.
Fair enough! How about the patch below then? Tested with and
without WANT_NEAR_INDICATION defined this time.
Or would you rather see a patch that remove WANT_NEAR_INDICATION
altogether?
On Tue, 5 Jul 2011, Alexandre Julliard wrote:
This does not fix a bug or add a feature, but it makes the coder easier
to follow. Narrower scope tends to be a good thing for variables, both
for human readers and compilers (though modern ones should not need the
hint).
Not necessarily, that's
of programming C. :-(
Sorry!
Gerald
On Wed, 15 Jun 2011, Gerald Pfeifer wrote:
Anything wrong with this patch? The original code surely looks wrong?
The difference between two pointers (of the same type) is the number
of elements, not the number of bytes. Thus the code below was way
incorrect
On Mon, 9 May 2011, Andrew Eikum wrote:
Anyways this is a tiny hassle, so I'm fine with it. Perhaps you should
consider filing a FreeBSD bug?
Sure thing, Andrew! That's sounds like a good idea (no pun intended :-).
http://www.freebsd.org/cgi/query-pr.cgi?pr=157050
Gerald
On Mon, 9 May 2011, Andrew Eikum wrote:
Makes sense to me. Thanks. Do this patch and the float format patch
together fix your build issues, Gerald?
The short answer is: Yes!
The long answer is that here have been three different issues around OSS
on current versions of FreeBSD where out of
On Mon, 23 May 2011, Marvin wrote:
VM StatusNumber of test failures
WINEBUILDcompleted
WNT4WSSP6completed 0
W2KPROSP4completed 0
WXPPROSP3completed 0
W2K3R2SESP2 failed
WVISTAADMcompleted 0
On Wed, 16 Feb 2011, Alexandre Julliard wrote:
This is the first hunk of a patch a few days ago; testbot.winehq.org
thinks it's fine: https://testbot.winehq.org/JobDetails.pl?Key=9291
You don't need casts. If the variable has the wrong type you can change
that.
At first I didn't realize what
I admit I am surprised that
Commit: 46988651d91fbea7f611287e5d8320239e72108d
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=46988651d91fbea7f611287e5d8320239e72108d
Author: Nicolas Le Cam niko.lecam at gmail.com
Date: Fri Apr 29 23:57:09 2011 +0200
gdi32: Remove a set
On Fri, 6 May 2011, Andrew Eikum wrote:
If Wine is trying to build wineoss.drv, then you must have oss_sysinfo.
If you have oss_sysinfo, then you have OSSv4. If you have OSSv4, then
you should have all of the above symbols, but apparently you don't. So I
suspect it's something amiss with
On Fri, 29 Apr 2011, Gerald Pfeifer wrote:
commit be332326ba8fc3def406c5f29adf04fbe9a83976
Author: Andrew Eikum aei...@codeweavers.com
Date: Wed Apr 27 09:12:36 2011 -0500
is causing the following build failures on my nightly FreeBSD testers:
mmdevdrv.c:463:20: error
I believe
commit be332326ba8fc3def406c5f29adf04fbe9a83976
Author: Andrew Eikum aei...@codeweavers.com
Date: Wed Apr 27 09:12:36 2011 -0500
is causing the following build failures on my nightly FreeBSD testers:
mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this
On Sun, 17 Apr 2011, Michael Stefaniuc wrote:
Of course it doesn't triggers in Wine as -Wpointer-arith is already
enabled. I made heavy use of that when I did my pointer cast killing
spree a few years ago.
Of course! I had missed the fact that this was not in the list of
regular options,
Matteo et al,
there is some code in dlls/d3dx9_36/surface.c which GCC struggles with
(in the sense of warning about it), and so do I, so I am wondering whether
you can have a look?
Specifically, in point_filter_simple_data we have:
DWORD val = 0, pixel;
/* extract source color
On Wed, 16 Feb 2011, Alexandre Julliard wrote:
The variable is here for documentation, you don't want to remove it. You
can comment it out if it's not used.
Fair enough! Updated patch below.
Gerald
ChangeLog:
winmm: Comment out unused variable in Simplify MCI_DumpCommandTable.
diff --git
On Sun, 13 Feb 2011, Janne Hakonen wrote:
Actually, now with your change you are comparing ULONG_PTR to ULONG.
With 64 bit binary the left side of comparison is a 64 bit pointer and
right side is 32 bit value.
Thanks, Janne. I have adjusted, tested and resubmitted the first
hunk of the
On Sun, 13 Feb 2011, Marvin wrote:
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
test_TCS_OWNERDRAWFIXED in dlls/comctl32/tests/tab has the following
code:
LPARAM lparam, lparam2;
:
lparam = 0;
memset(lparam, 0xde, 4);
memset(lparam2, 0xde, sizeof(LPARAM)-1);
ok(g_drawitem.itemData == lparam || broken(g_drawitem.itemData == lparam2) /*
win98 */,
got
Dec 2009, James McKenzie wrote:
Nikolay Sivov wrote:
On 12/26/2009 00:04, James McKenzie wrote:
Nikolay Sivov wrote:
On 12/25/2009 14:18, Gerald Pfeifer wrote:
Otherwise max_count will be undefined in the following loop may do
interesting things it seems. (Does Coverity diagnose
On Tue, 28 Sep 2010, Juan Lang wrote:
This mimicks what we already do a few lines above for buf_type.
It's also unneeded:
switch(ioctl 0x1800)
There are only 4 possible combinations of ioctl 0x1800. Three
are covered in this switch statement, and the fourth is eliminated
On Mon, 3 Jan 2011, Alexandre Julliard wrote:
I verified this does not cause any warning on FreeBSD 8.1 test
builds, and all the tools like bison and flex in somewhat current
versions.
It's broken here with bison 2.4.1:
make[1]: Entering directory `/home/julliard/wine/wine/libs/wpp'
gcc
On Tue, 21 Sep 2010, Alexandre Julliard wrote:
I still see a ton of warnings here (gcc 4.4.5), mostly because of the
glibc string macros.
Hmm, I see. Still, this is really useful to have. How about the patch
below as an alternative? Additional platforms can add this when/if they
want.
Hi Thomas,
the following change of yours
commit bced2e21dbc548ef9d41e3ff11384d7ad964c929
Author: Thomas Mullaly thomas.mull...@gmail.com
Date: Sat Oct 9 11:02:17 2010 -0400
urlmon: Implemented base case for CoInternetCombineIUri.
introduces a new warning, use of uninitialized
On Mon, 20 Sep 2010, Alexandre Julliard wrote:
In the past this has found a dozen or two real issues and lead to some
simplifications. Now the tree is clean in that regard, so we can make
this a default.
I still see a ton of warnings here (gcc 4.4.5), mostly because of the
glibc string
On Mon, 4 Jan 2010, Henri Verbeet wrote:
I dont see a reason to take that warning serious, as its not a problem
in any case. in kernel32 it just happens because we use a Macro.
Taking that case(v==1) out of the Macro leads to harder readable code.
So IMHO i would not make -Wlogical-op the
On Tue, 25 May 2010, Alexandre Julliard wrote:
An alternate patch would be putting #if 0 around the first occurrence
of loadhigh, too, but this code has been marked dead for more than 11
years, so I really think it can / should go?
It doesn't make sense to parse and not do anything with it. If
On Tue, 18 May 2010, Gerald Pfeifer wrote:
Using autoconf 2.62 on my primary test system I am getting:
configure:26081: error: possibly undefined macro: AS_VAR_IF
Indeed use of AS_VAR_IF appears relatively new, and it seems this may be
similar to AS_VAR_APPEND where we have
On Tue, 20 Jul 2010, Alexandre Julliard wrote:
@@ -388,6 +388,8 @@ static int DIB_GetBitmapInfo( const BITMAPINFOHEADER
*header, LONG *width,
*compr = header-biCompression;
return 1;
}
+
+*width = *height = 0;
ERR((%d): unknown/wrong size for header\n,
On Sun, 14 Feb 2010, James McKenzie wrote:
Please take time to read through the remainder of the posts here, even
though you've been here for a while. It is NOT possible to build Wine
without some sort of X on the build computer right now.
Yep, I know. Which is why I wondered that configure
On Thu, 19 Aug 2010, Matteo Bruni wrote:
Hmm, so srcidx is unused. Yes, that piece of code is useless now, it's
a remnant of an older version of that function where the source
register was handled by some ad-hoc code, which I since then replaced
with a call to the generic This-funcs-srcreg().
Metteo et al,
I noticed d3dx9_36/bytecodewriter.c can be simplified as follows, but
somewhat tells me this may rather point out a problem somewhere in that
code, so I am not sending this to wine-patches.
(The only functional difference should be the missing WARN in some cases,
and I could
On Mon, 10 May 2010, Nikolay Sivov wrote:
-static inline BOOL is_textT(LPCWSTR text, BOOL isW)
+static inline BOOL is_textT(LPCWSTR text)
There's no reason to keep this helper then. It's better to rename
is_textW() to is_text() and remove is_textT().
Excellent idea. I'll submit a patch to
Using autoconf 2.62 on my primary test system I am getting:
configure:26081: error: possibly undefined macro: AS_VAR_IF
Indeed use of AS_VAR_IF appears relatively new, and it seems this may be
similar to AS_VAR_APPEND where we have the following in configure.ac:
dnl autoconf versions
On Sun, 9 May 2010, Nikolay Sivov wrote:
I don't think it's dead. Variable ptr is used in a cycle.
You are amazing. And right. I just submitted an updated patch.
Gerald
On Sun, 9 May 2010, Vitaliy Margolen wrote:
On 05/07/2010 01:06 PM, Gerald Pfeifer wrote:
-oldPen = SelectObject(hdc, greenPen);
+SelectObject(hdc, greenPen);
If it's not used it's a bug. Everything should be reset to original
state to prevent influence on following tests
On Thu, 6 May 2010, Nikolay Sivov wrote:
-res = SendMessage(hwnd, MCM_GETMINREQRECT, 0, (LPARAM)r1);
+SendMessage(hwnd, MCM_GETMINREQRECT, 0, (LPARAM)r1);
Actually it won't hurt to test for it here.
Okay. I am currently testing a patch that does exactly that in both
cases. Thanks for
On Tue, 11 May 2010, James Hawkins wrote:
I'm very hesitant about this. MSDN has no documentation about
RegisterOCX, so I'm not sure how you're justifying this change. It's
been a long time since I worked on this, so I don't remember much, but
I do remember testing this method and
On Mon, 10 May 2010, Alexandre Julliard wrote:
dlls/gdi32/metafile.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
It seems pretty clear that it should be used, not removed.
Eeeh. That one's worth a drink the next (= first) time we meet in
person.
(On the positive side, at
On Sun, 9 May 2010, test...@testbot.winehq.org wrote:
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
On Sun, 9 May 2010, test...@testbot.winehq.org wrote:
While running your changed tests on Windows, I think I found new
failures. Being a bot and all I'm not very good at pattern recognition,
so I might be wrong, but could you please double-check? Full results can
be found at
On Sun, 9 May 2010, test...@testbot.winehq.org wrote:
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=1983
Another false positive.
W7PROcompleted 39
W7PROX64 completed 19
W7PROX64 completed 19
...is the same before and
Looking at
RPC_STATUS WINAPI RpcBindingVectorFree( RPC_BINDING_VECTOR** BindingVector )
{
RPC_STATUS status;
ULONG c;
TRACE((%p)\n, BindingVector);
for (c=0; c(*BindingVector)-Count; c++) {
status = RpcBindingFree((*BindingVector)-BindingH[c]);
}
On Sun, 9 May 2010, test...@testbot.winehq.org wrote:
=== WINEBUILD (build) === Patch failed
The issue was that a previous patch of mine (which got accepted)
conflicted and my local tree was not right. Fixed and resubmitted,
testing at Wine Test Bot went well now:
On Mon, 3 May 2010, Jacek Caban wrote:
On 5/2/10 9:16 PM, Gerald Pfeifer wrote:
IActiveScriptSite_OnStateChange is described to return S_OK upon
success, so instead of ignoring its return value and unconditionally
returning S_OK it strikes me that we should return its result instead
On Mon, 3 May 2010, Nikolay Sivov wrote:
Bitmap are useless after this change.
I'll submit a patch which has this fixed. Interestingly, at least on
my FreeBSD-based tester, test results did _not_ regress either way.
Gerald
On Wed, 5 May 2010, test...@testbot.winehq.org wrote:
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
On Mon, 3 May 2010, Nikolay Sivov wrote:
Bitmap are useless after this change.
Darn, I may have sent the wrong version of the patch. Let me look
into this tonight or tomorrow.
You have sharp eyes, Nikolay! :-)
Gerald
is
going to help -- do we want to abort for newer versions when these
actually should be compatible?)
Gerald
From: Gerald Pfeifer ger...@pfeifer.com
Date: Sun, 2 May 2010 22:05:20
Subject: dbghelp: Remove two variables which are not really used in
dwarf2_parse_line_numbers.
---
dlls/dbghelp
On Sun, 2 May 2010, Nikolay Sivov wrote:
Please use consistent naming for patches and mail subjects. It's
described in http://wiki.winehq.org/SubmittingPatches.
I'm not sure it makes sense to resend all these, but GERALD: as a
start word is unacceptable of course.
Indeed, four or so
On Thu, 22 Apr 2010, Nikolay Sivov wrote:
You can't do this, subclassing is important thing here. And you will see
it if you run a test (that you should do before sending patch actually).
Thanks, Nikolay. You're perfectly right, that was a silly mistake of
mine, no way to put this
On Sat, 1 May 2010, Nikolay Sivov wrote:
ChangeLog:
Remove variable res which is not really used from test_XcvClosePort.
We should better test for return value than remove it.
This is a primitive thing, try it if you didn't before.
All you need is to add some lines like:
---
ok(res ==
On Sat, 24 Apr 2010, Nikolay Sivov wrote:
ChangeLog:
Remove variable res which is not really used from test_XcvClosePort.
We should better test for return value than remove it.
Okay. Is this something you can look into (or do you have a hint
on how you'd like such a test to look like)? It
Trying to build Wine on a new tester which initially had too few packages
installed I ran into the following.
In file included from bitblt.c:33:
x11drv.h:30:22: error: X11/Xlib.h: No such file or directory
x11drv.h:31:27: error: X11/Xresource.h: No such file or directory
x11drv.h:32:23:
On Wed, 27 Jan 2010, Tom Wickline wrote:
The version check fails on FreeBSD 8 even tho flex-2.5.35_3 is
installed from ports.
# flex --version
flex version 2.5.4
The version check passes on Linux and OpenSolaris but FreeBSD has a
harder time with it.
Gerald has a workaround for this..
On Fri, 29 Jan 2010, Austin English wrote:
Right. But it's a bug in the sense that FreeBSD is shipping an
_extremely_ old version of flex ;-).
True.
Can you put in a request to update flex for FreeBSD 8.1/9.0? Or
should I register/file a bug?
Filing a request is fine, if you want to do so.
On Fri, 29 Jan 2010, Austin English wrote:
Flex isn't GLPv3, it's got a BSD license:
http://flex.sourceforge.net/manual/Copyright.html#Copyright
You're right, and I had actually checked that a few weeks ago and
confused it with something else now.
Excellent. Please do file a PR against
On Tue, 23 Jun 2009, Paul Vriens wrote:
For those interested, here's the make log in Monday's git. 94 warnings
for me.
Sent 3 patches based on your log.
I have less (55) warnings on 4.3.2 btw, but most look like false positives.
On my FreeBSD test system I am see no warnings triggered by
On Sun, 3 Jan 2010, Austin English wrote:
On my FreeBSD test system I am see no warnings triggered by -Wlogical-op
any more. How does it look on your side?
ole32:
usrmarshal.c:485: warning: logical ?? with non-zero constant will
always evaluate as true
usrmarshal.c:1098: warning: logical ??
I believe the following patch
commit 8268ed978389662c7b43212e008037cae3ce900e
Author: Alexandre Julliard julli...@winehq.org
Date: Mon Dec 28 22:19:31 2009 +0100
kernel32: Do not include 16-bit headers in 32-bit files.
is causing
gmake[2]: Entering directory
On Thu, 31 Dec 2009, Reece Dunn wrote:
Have you tried this patch?:
http://www.winehq.org/pipermail/wine-patches/2009-December/083364.html
(This is in the latest git --
Yep, that works. Thanks!
Gerald
On Thu, 24 Dec 2009, Henri Verbeet wrote:
Done thusly. We just need to move WINEMAKEFOURCC to a local header,
the rest of the cpp_quote can go and we lose a couple of dozen warning
messages (rightfully) issued by GCC 4.5 snapshots.
I already sent pretty much the same patch,
feedback you provided, and than show
why I started down this road.
On Thu, 2 Jul 2009, Rob Shearman wrote:
2009/6/28 Gerald Pfeifer ger...@pfeifer.com:
diff --git a/tools/widl/parser.y b/tools/widl/parser.y
index c2f1abc..01aa060 100644
--- a/tools/widl/parser.y
+++ b/tools/widl/parser.y
On Tue, 6 Oct 2009, Alexandre Julliard wrote:
If you prefer, I'll be happy to convert the code into a switch statement.
Just let me know!
That would certainly be more elegant.
Your wish is my command. :-)
Gerald
ChangeLog:
Add support for PLATFORM_FREEBSD to get_ld_command.
diff --git
Strike that, I must have misread the documentation.
Only thing I am wondering is do we really need the (unsigned long) here?
If anyone has a pointer to clear documentation that would be nice; what I
found so far leaves some questions open...
Gerald
On Sun, 28 Jun 2009, Gerald Pfeifer wrote
On Sat, 20 Jun 2009, Paul Vriens wrote:
- if (!ci-u1.dlstLightStateType
(ci-u1.dlstLightStateType D3DLIGHTSTATE_COLORVERTEX))
+if (!ci-u1.dlstLightStateType ||
(ci-u1.dlstLightStateType D3DLIGHTSTATE_COLORVERTEX))
Would:
if ((ci-u1.dlstLightStateType
On Fri, 19 Jun 2009, Ben Klein wrote:
diff --git a/configure.ac b/configure.ac
index bef311e..3f7a657 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1385,8 +1385,9 @@ then
WINE_TRY_CFLAGS([-fno-builtin],[AC_SUBST(BUILTINFLAG,-fno-builtin)])
WINE_TRY_CFLAGS([-fno-strict-aliasing])
On Thu, 18 Jun 2009, Austin English wrote:
Causes 106 more warnings on 4.3.3 of this sort:
tab.c:693: warning: logical ?? with non-zero constant will always
evaluate as true
cert.c:1627: warning: logical ?||? with non-zero constant will always
evaluate as true
This is strange. In that case,
On Fri, 19 Jun 2009, Rein Klazes wrote:
cert.c:1627: warning: logical ?||? with non-zero constant will always
evaluate as true
That (in dlls/crypt32/tests) looks like a real bug to me.
Indeed. And Alexandre committed a fix of mine in the last 24 hours. ;-)
Gerald
On Fri, 19 Jun 2009, Paul Vriens wrote:
I have about 70 warnings with 4.3.2.
I already sent two patches and found a few more bugs. If you want I can
start sending in patches for those as well (don't want to duplicate work
of course).
Thanks for checking to help avoid duplicate work, Paul;
In dlls/winedos/int10.c we currently have the following code
VGA_SetBright((BL_reg(context) 0x10) 1);
which I am not sure I understand. Is the purpose of this to only pass
one of 0 or 1 to VGA_SetBright? If so, I guess I'd find ... ? 1 : 0
more intuitive, and it's only three characters
On Mon, 11 May 2009, Alexandre Julliard wrote:
I don't have gcc 4.5 to test this, but you could try using a function
instead, something like this:
diff --git a/include/winnt.h b/include/winnt.h
index abcc502..aaa4112 100644
--- a/include/winnt.h
+++ b/include/winnt.h
@@ -292,7 +292,7 @@
On Mon, 11 May 2009, Alexandre Julliard wrote:
2. More importantly, these were the only occurences of C_ASSERT at
file level. By moving these at function level use thereof becomes
consistent which will allow the fix from PATCH 2/2 to work at all.
C_ASSERT is supposed to work at the
On Mon, 2 Feb 2009, Francois Gouget wrote:
/* case RB_SETCOLORSCHEME: */
/* case RB_SETPALETTE: */
-/* return REBAR_GetPalette (infoPtr, wParam, lParam); */
case RB_SETPARENT:
Once the commented out return has been removed it looks like
RB_SETCOLORSCHEME and RB_SETPALETTE
On Fri, 9 Jan 2009, Gerald Pfeifer wrote:
I am not aware of one. Tijl and me actually argued to get the
original behavior back (for this and other reasons like source
compatbility) but failed. I just pushed again.
FreeBSD upstream is not going to change, from what I can tell, so we
really
On Fri, 9 Jan 2009, Francois Gouget wrote:
On Thu, 1 Jan 2009, Gerald Pfeifer wrote:
[...]
ChangeLog:
Only use RTF_LLINFO if #defined, fixing FreeBSD 8 after the arp-v2
rewrite.
[...]
#if defined(HAVE_SYS_SYSCTL_H) defined(NET_RT_DUMP)
- int mib[] = {CTL_NET, PF_ROUTE, 0, AF_INET
On Wed, 31 Dec 2008, Alexandre Julliard wrote:
Gerald Pfeifer ger...@pfeifer.com writes:
The current version likely is actually broken since the ! operator has
a higher priority than bitwise in C. Unless someone really wanted to
use a very, hmm, unusual construct here?
No, it's clearly
On Sat, 27 Dec 2008, ricardo filipe wrote:
are you sure windows doesn't call those functions with those parameters? you
have to check that before sending patches like these ...
Yes, I am. Looking at the patch...
static LRESULT
-NATIVEFONT_Create (HWND hwnd, WPARAM wParam, LPARAM lParam)
I am mostly offline (2s ping times) for another two weeks, but noticed
the following starting a couple of days ago on my nightly FreeBSD 6.4
tester:
server.c:755: warning: implicit declaration of function '_mkdir'
shellpath.c:2163: warning: implicit declaration of function '_mkdir'
On Tue, 9 Sep 2008, Rob Shearman wrote:
-static HRESULT Registrar_create(const IUnknown *pUnkOuter, REFIID riid,
void **ppvObject)
+static HRESULT Registrar_create(REFIID riid, void **ppvObject)
A test needs to be added to see whether or not the Registrar class
factory supports aggregation.
On Thu, 21 Aug 2008, Hans Leidekker wrote:
Thanks. I didn't want to copy all of the ifdef blocks from wininet
because I can't verify which ones are actually needed. So I'm counting
on people like you to fix this up, and I'm sure I'll need your help
again :)
You're welcome. :-) Wine build
On Thu, 5 Jun 2008, James Hawkins wrote:
http://winehq.org/pipermail/wine-cvs/2008-June/044013.html
I'm getting old and slow, I guess. :-/
Gerald
On Fri, 2 May 2008, Robert Shearman wrote:
It turns out that current versions of bison do not enforce the documented
grammer as strictly as older ones such as bison 1.75. Fixed thusly.
Oops, thanks for spotting it. Actually, I was developing on version 1.28
and didn't get those errors so it
After the following change about a week ago
Rob Shearman [EMAIL PROTECTED]
widl: Make the rules for parsing fields in structures, encapsulated unions
and non-encapsulated unions more strict.
Move the rules in fields that handle empty union cases into separate
union rules so that they
On Wed, 16 Apr 2008, James Hawkins wrote:
Beat ya to the punch :)
Better twice than not at all, to paraphrase a German saying. :-)
Gerald
On Sun, 17 Feb 2008, James Hawkins wrote:
static INT add_streams_to_table(MSISTREAMSVIEW *sv)
+/* Return -1 in case of error. */
Don't add random comments like this.
Okay, will keep this in mind, especially for dlls/msi.
Gerald
A second one which Marcus ended up reinventing, but at least the
underlying problem is solved now. :-/
Gerald
On Wed, 26 Dec 2007, Gerald Pfeifer wrote:
Okay. In that case, to account for possible future enhancements of
ImmGetCompositionStringW(), we'll need a patch like the following
For the record, while I don't think I saw a response to this, the
issue itself was now fixed with basically the same patch submitted
by Marcusso we can remove this from our radars.
Thanks for trying again, Marcus! :-)
Gerald
On Sat, 3 Nov 2007, Gerald Pfeifer wrote:
Good observation, though
On Sat, 16 Feb 2008, Alexandre Julliard wrote:
The test should probably be removed completely since there's already a
default for it in the switch() that follows.
I was thinking of this, but wanted to go for the smaller patch initially,
but your wish is my command ;-).
Updated patch below.
On Wed, 6 Feb 2008, Alexandre Julliard wrote:
The reason is that we have
#define HDPTOLP(y) ((y0)? \
(-abs(INTERNAL_YDSTOWS(dc, (y: \
(abs(INTERNAL_YDSTOWS(dc, (y)
which is overly complicated for
On Mon, 14 Jan 2008, Alexandre Julliard wrote:
@@ -4348,12 +4349,12 @@ static void vshader_version_varying_test
vs_3_0 returned color 0x%08x, expected 0x00203366\n, color);
color = getPixelColor(device, 160, 360);
ok((color 0x00ff) = 0x003c (color 0x00ff) =
On Wed, 26 Dec 2007, Alexandre Julliard wrote:
dwBufLen already indictes that this variable is of type DWORD and
thus always positive. I also looked at the implementation of
ImmGetCompositionStringW() and we do not seem to return a negative
value (such as -1).
Maybe the implementation
On Sun, 4 Nov 2007, Gerald Pfeifer wrote:
The only patch I can think of that avoid *both* warnings is the one
below. Not perfect, but I fair compromise. What do you think? Or
do you have any better idea that we might want to try?
For the record, your fix that you committed yesterday
On Thu, 29 Nov 2007, Alexandre Julliard wrote:
I checked again and if we don't address this we'll get two new warnings
issues in a default build with GCC 4.3. How does the patch below
look?
Not good, it adds noise to the code for no good reason. Why would gcc
complain about that one?
GCC
On Mon, 19 Nov 2007, Alexandre Julliard wrote:
I had expected this comment for a different patch of mine. In
dlls/gdi32/enhmetafile.c we are just reading existing records,
so I'm not sure what you have in mind here?
The records usually come from an external file, so they have to be
On Sun, 2 Dec 2007, Alexandre Julliard wrote:
I'm aware of that, but the purpose of having these warnings is to spot
bugs, and when you find a bug you have to fix it. Yes, the checks
currently don't work, so they should be made to work, not removed. As
the comment says, you have to check that
This change of mine is obvious since InExt and OutExt are DWORD, thus
unsigned, and thus always greater or equal zero so my patch should be
fine in any case.
However, looking at the else-part of the if-statement, I have some
doubts this is working as designed, and in general the abs() invocations
Hi Alexandre,
On Wed, 21 Nov 2007, Alexandre Julliard wrote:
If applied, I will commit to address, directly and by engaging others,
the occurrences of such warnings in Wine.
I'm not opposed to applying it, but you have to fix the warnings first,
as far as possible the default build should not
1 - 100 of 210 matches
Mail list logo
