Use of uninitialized variable in combine_uri()
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 variable in the line
marked HERE below.
+static HRESULT combine_uri(Uri *base, Uri *relative, DWORD flags, IUri
**result
+Uri *ret;
+HRESULT hr;
+parse_data data;
+
+/* Base case is when the relative Uri has a scheme name,
+ * if it does, then 'result' will contain the same data
+ * as the relative Uri.
+ */
+if(relative-scheme_start -1) {
+DWORD create_flags = 0;
+
+memset(data, 0, sizeof(parse_data));
+
+data.uri = SysAllocString(relative-raw_uri);
+if(!data.uri) {
+IUri_Release(URI(ret)); == HERE
+*result = NULL;
+return E_OUTOFMEMORY;
+}
From all I can tell this is a legitimate warning, that is, the code
really invokes undefined behavior. Would you mind having a look?
Gerald
Re: ddraw: Exclusive mode is the corner case for SetCooperative, not the normal mode.
Hi, 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/JobDetails.pl?Key=6757 Your paranoid android. === W98SE (32 bit ddrawmodes) === ddrawmodes: unhandled exception c005 at 004122E8 === W7PROX64 (64 bit ddrawmodes) === Timeout
Re: [6/6] msvcr80/tests: _itow_s tests
Hi, 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/JobDetails.pl?Key=6762 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [5/6] msvcr80/tests: qsort_s tests
Hi, 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/JobDetails.pl?Key=6761 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [4/6] msvcr80/tests: install test files
Hi, 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/JobDetails.pl?Key=6760 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: Voting for bugs (Was: Re: [Bug 20969])
Yaron Shahrabani sh.ya...@gmail.com wrote: I think that voting for bugs is a great feature, otherwise there would have been many annoying comments like: it happens to me too and what info you can get out of it? Adding such a comment is pefectly acceptable. Confirming a bug and voting for it are two different things. Once a bug is confirmed its state changes from UNCONFORMED to NEW, and usually once sombody else bisides the reporter confirms a bug, a person with appropriate bugzilla rights sets bug state to NEW. But asking people to vote for a bug is a waste of effort, since that doesn't change anything. There are bugs in Wine bugzilla with huge amounts of votes on them, but that doesn't suddenly make a bug more important to developers for various reasons. Voting helps setting priorities for bugs without nonsense comments. That's the bug severity is for. -- Dmitry.
Re: msvcrt: Implement _get_tzname.
Eryk Wieliczko ewde...@gmail.com wrote:
-static char tzname_std[64] = ;
-static char tzname_dst[64] = ;
+static char tzname_std[64] = PST;
+static char tzname_dst[64] = PDT;
char *MSVCRT__tzname[2] = { tzname_std, tzname_dst };
...
This is not an implementation, this is a quick and dirty hack.
--
Dmitry.
Re: [PATCH 01/14] [Msvcrt]: now using macro for parameters validation itoa_s (and updated the tests as well)
Eric Pouech eric.pou...@orange.fr writes: +/* As of today, native and builtin msvcr80, msvcr90, msvcr100 raise an exception on CRT + * parameter checking on secure + * As Wine forwards most of the APIs of those msvcrNN DLLs to msvcrt, builtin msvcrt does + * raise an exception on those cases + * Testing shows that native msvcrt doesn't + * So we make this test always succeed under Windows + */ That's not very useful. This should be tested in msvcr90, where we can properly check whether the handler is called. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 10/14] [Msvcrt*]: implemented _vc(w)printf
Eric Pouech eric.pou...@orange.fr writes:
+int CDECL _vcprintf(const char* format, __ms_va_list xvalist)
{
char buf[2048], *mem = buf;
int written, resize = sizeof(buf), retval;
- __ms_va_list valist;
+ __ms_va_list valist = xvalist;
You can't copy a valist. This needs to be integrated properly with the
other printf functions.
--
Alexandre Julliard
julli...@winehq.org
Re: xlive: add initial stub dll (1/3)
Am 03.11.2010 um 06:00 schrieb Scott Ritchie: From a usability perspective we're not going to be doing much good unless this happens near-automatically with a typical Wine installation. That means either including them in Wine directly or including hooks to download them when needed (this could also be done in the packaging layer) Another thing I wondered about: Can those DLLs be compiled outside the main wine tree? It'd seem nicer to me to have a project with just the DLL as opposed to a clone of the entire wine tree. As for the server parts of xlive, I guess to get them working with a builtin DLL we'd have to build our own server infrastructure. Even then it would be an entirely different set of users and data than what you get on Windows.
Re: include: Add IDirect3DRMWinDevice interface (try 2)
On 2 November 2010 23:28, Vijay Kiran Kamuju infyqu...@gmail.com wrote: +#include d3drm.h + +#include d3drm.h I'd expect once to be enough.
Re: [4/4] msxml3: Fix node_get_text() whitespace handling (resend)
Adam Martinson amartin...@codeweavers.com writes:
@@ -68,6 +68,8 @@ static const WCHAR szBinHex[] =
{'b','i','n','.','h','e','x',0};
static const IID IID_xmlnode =
{0x4f2f4ba2,0xb822,0x11df,{0x8b,0x8a,0x68,0x50,0xdf,0xd7,0x20,0x85}};
+BOOL is_preserving_whitespace(xmlNodePtr node);
Please put function prototypes in msxml_private.h.
--
Alexandre Julliard
julli...@winehq.org
Re: [2/6] msvcr80: qsort_s implementation (try 2)
Vincas Miliūnas vincas.miliu...@gmail.com writes: qsort_s and _itow_s implementation and tests for bug #24925. These should go in msvcrt, and the tests in msvcr90. msvcr80 is a simple forwarding dll. -- Alexandre Julliard julli...@winehq.org
Re: [2/6] msvcr80: qsort_s implementation (try 2)
Alexandre Julliard julli...@winehq.org writes: Vincas Miliūnas vincas.miliu...@gmail.com writes: qsort_s and _itow_s implementation and tests for bug #24925. These should go in msvcrt, and the tests in msvcr90. msvcr80 is a simple forwarding dll. To clarify, the tests should go in msvcr90 if the functions don't exist in native msvcrt (or if their behavior is different, for instance WRT the invalid parameter callback). Otherwise the tests should of course be in msvcrt along with the implementation. -- Alexandre Julliard julli...@winehq.org
Re: [6/6] msvcr80/tests: _itow_s tests (try 2)
Hi, 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/JobDetails.pl?Key=6768 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [5/6] msvcr80/tests: qsort_s tests (try 2)
Hi, 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/JobDetails.pl?Key=6767 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: [4/6] msvcr80/tests: install test files (try 2)
Hi, 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/JobDetails.pl?Key=6766 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
make crosstest fails for _fseeki64 and _ftelli64
I am working on a test for _fseeki64 and _ftelli64. brutalcompu...@brutalcomputer-laptop:~/wine-git/dlls/msvcrt/tests$ vim file.c brutalcompu...@brutalcomputer-laptop:~/wine-git/dlls/msvcrt/tests$ make crosstest i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -DWINE_STRICT_PROTOTYPES -DWINE_CROSSTEST -Wall -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 -o file.cross.o file.c file.c: In function ‘create_io_inherit_block’: file.c:942: warning: dereferencing type-punned pointer will break strict-aliasing rules ../../../tools/winegcc/winegcc -b i586-mingw32msvc -B../../../tools/winebuild --sysroot=../../.. --lib-suffix=.cross.a cpp.cross.o data.cross.o dir.cross.o environ.cross.o file.cross.o headers.cross.o heap.cross.o locale.cross.o misc.cross.o printf.cross.o scanf.cross.o signal.cross.o string.cross.o time.cross.o testlist.cross.o -o msvcrt_crosstest.exe file.cross.o: In function `func_file': /home/brutalcomputer/wine-git/dlls/msvcrt/tests/file.c:1474: undefined reference to `__ftelli64' collect2: ld returned 1 exit status winegcc: i586-mingw32msvc-gcc failed make: *** [msvcrt_crosstest.exe] Error 2 brutalcompu...@brutalcomputer-laptop:~/wine-git/dlls/msvcrt/tests$ of course make test works perfectly. My guess is that mingw doesn't support _ftelli64 and _fseeki64. What should I do in this situation?
Re: [PATCH] more stubs for mprapi.dll
On Wed, Nov 3, 2010 at 6:39 PM, netzi...@aim.com wrote: [PATCH] more stubs for mprapi.dll The patch is gibberish. Additionally, please include your full real name when submitting patches to wine. -- -Austin
Re: First contact
Hi everyone, Sorry for flooding, but I'm stuck with my bug, I try several debug output channel (+heap, +snoop etc.) but the log shows nothing. It's like I click on the start button and boom! Access_violation exception. And what's weird is that the game is still running. I thought that an access violation exception causes the application to crash. Here I can do an ALT-TAB then go back to the game. The music still playing, the background image still here, the mouse still moving. Is that normal? I updated the bug with my log file : http://bugs.winehq.org/show_bug.cgi?id=18014 http://bugs2.winehq.org/attachment.cgi?id=31576 I really don't know where to look. Any hint?? There must be a way to know what causes this exception, no? Greetings, Andréas
re: First contact
It's probably your game's copy protection. We can't advise you on circumventing it. The question probably belongs on wine-users, not wine-devel...
Re: [2/2] msvcrt/tests: qsort_s implementation and tests (try 3)
Hi, 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/JobDetails.pl?Key=6778 Your paranoid android. === WINEBUILD (build) === Patch failed to apply
Re: msvcrt/tests: _itow_s tests (try 3)
Hi, 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/JobDetails.pl?Key=6779 Your paranoid android. === WVISTAADM (32 bit string) === string.c:1446: Test failed: expected invalid_parameter_handler string.c:1455: Test failed: expected invalid_parameter_handler string.c:1464: Test failed: expected invalid_parameter_handler string.c:1473: Test failed: expected invalid_parameter_handler string.c:1485: Test failed: expected invalid_parameter_handler string.c:1497: Test failed: expected invalid_parameter_handler string.c:1509: Test failed: expected invalid_parameter_handler === W2K8SE (32 bit string) === string.c:1446: Test failed: expected invalid_parameter_handler string.c:1455: Test failed: expected invalid_parameter_handler string.c:1464: Test failed: expected invalid_parameter_handler string.c:1473: Test failed: expected invalid_parameter_handler string.c:1485: Test failed: expected invalid_parameter_handler string.c:1497: Test failed: expected invalid_parameter_handler string.c:1509: Test failed: expected invalid_parameter_handler === W7PRO (32 bit string) === string.c:1446: Test failed: expected invalid_parameter_handler string.c:1455: Test failed: expected invalid_parameter_handler string.c:1464: Test failed: expected invalid_parameter_handler string.c:1473: Test failed: expected invalid_parameter_handler string.c:1485: Test failed: expected invalid_parameter_handler string.c:1497: Test failed: expected invalid_parameter_handler string.c:1509: Test failed: expected invalid_parameter_handler === W7PROX64 (32 bit string) === string.c:1446: Test failed: expected invalid_parameter_handler string.c:1455: Test failed: expected invalid_parameter_handler string.c:1464: Test failed: expected invalid_parameter_handler string.c:1473: Test failed: expected invalid_parameter_handler string.c:1485: Test failed: expected invalid_parameter_handler string.c:1497: Test failed: expected invalid_parameter_handler string.c:1509: Test failed: expected invalid_parameter_handler === W7PROX64 (64 bit string) === string.c:1446: Test failed: expected invalid_parameter_handler string.c:1455: Test failed: expected invalid_parameter_handler string.c:1464: Test failed: expected invalid_parameter_handler string.c:1473: Test failed: expected invalid_parameter_handler string.c:1485: Test failed: expected invalid_parameter_handler string.c:1497: Test failed: expected invalid_parameter_handler string.c:1509: Test failed: expected invalid_parameter_handler
