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' f
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 current
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
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
&g
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?
G
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,
rs 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 c
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 t
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, 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
I admit I am surprised that
Commit: 46988651d91fbea7f611287e5d8320239e72108d
URL:
http://source.winehq.org/git/wine.git/?a=commit;h=46988651d91fbea7f611287e5d8320239e72108d
Author: Nicolas Le Cam
Date: Fri Apr 29 23:57:09 2011 +0200
gdi32: Remove a set but unused variable.
has
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
> Date: Wed Apr 27 09:12:36 2011 -0500
>
> is causing the following build failures on my nightly FreeBSD testers:
>
> mmdevdrv.c:463:20: er
I believe
commit be332326ba8fc3def406c5f29adf04fbe9a83976
Author: Andrew Eikum
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
function)
mmdevdrv.c:
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 com
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 p
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
> http://testbot.winehq.org/JobDet
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 0x%
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 f
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 elim
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'
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
>
Hi Thomas,
the following change of yours
commit bced2e21dbc548ef9d41e3ff11384d7ad964c929
Author: Thomas Mullaly
Date: Sat Oct 9 11:02:17 2010 -0400
urlmon: Implemented base case for CoInternetCombineIUri.
introduces a new warning, use of uninitialized variable in the line
marked "
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 stri
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 configu
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
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
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
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-
On Mon, 6 Sep 2010, Alexandre Julliard wrote:
>> 1. We only set, but never used cbres, so removing it loses nothing.
>> 2. With this patch we now set the return value to VCPN_FAIL in this
>> case. However, this is not the only case in vcpUICallbackProc16;
>> for example, in another case
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->srcre
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 restore
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 p
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 before
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 preve
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. Than
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 documen
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
> http://testbo
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 http://testb
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 af
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:
https://testbot.winehq.org/
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]);
}
HeapFree(
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 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 retu
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
> http://testbo
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
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:
> ---
> o
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 differentl
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 pa
checking for the DWARF version is
going to help -- do we want to abort for newer versions when these
actually should be compatible?)
Gerald
From: Gerald Pfeifer
Date: Sun, 2 May 2010 22:05:20
Subject: dbghelp: Remove two variables which are not really used in
dwarf2_parse_line_numbers.
--
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)? I
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: e
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 FreeB
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
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 f
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: l
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 triggere
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
I believe the following patch
commit 8268ed978389662c7b43212e008037cae3ce900e
Author: Alexandre Julliard
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 `/usr/test/Wine/dlls/kernel32'
/files/pfei
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,
> http://sou
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 :
>> diff --git a/tools/widl/parser.y b/tools/widl/parser.y
>> index c2f1abc..01aa060 100644
>> --- a/tools/widl/parser.y
>> +++ b/tools/
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.dls
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, P
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-
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
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
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
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_S
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 te
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
On Wed, 31 Dec 2008, Alexandre Julliard wrote:
> Gerald Pfeifer 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?
> N
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 lPara
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'
shfldr_unixfs.c
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 aggreg
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
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 fol
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.
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
On Wed, 6 Feb 2008, Alexandre Julliard wrote:
>> The reason is that we have
>>
>> #define HDPTOLP(y) ((y<0)? \
>> (-abs(INTERNAL_YDSTOWS(dc, (y: \
>> (abs(INTERNAL_YDSTOWS(dc, (y)
>>
>> which is overly compl
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 & 0x0
On Sun, 6 Jan 2008, Alexandre Julliard wrote:
> We don't use C99 features in Wine.
Actually we do.
% egrep -r "^(static )?inline " $WINE_SOURCE/ | wc -l
2031
"inline" is pretty similar to flexible array members in that both were
not in C90, both are in C99, and both have been GNU extensions
On Fri, 4 Jan 2008, Alexandre Julliard wrote:
>> -WORD thunks[4]; /* Each thunk is 4 words long */
>> +WORD thunks[]; /* Each thunk is 4 words long */
> That syntax is not portable.
That depends. ;-) You're right, it is not ISO C90, but it is in the
C99 standard which is now close to
On Sat, 1 Dec 2007, Gerald Pfeifer wrote:
> 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
&
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 implementati
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
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 th
1 - 100 of 233 matches
Mail list logo
