Re: advapi32/tests: Fix copypaste typo
Hi Andre,
According to my test plan of the registry merging project, I will add
new tests for HKCR. At first I tried to add them to the old code but I
find it become too long and hard-reading. I had to rewrite them to a
series of strict and neat tests, classified as read/write operations,
including keys values enumerating and deleting. I used many
pre-definitions which make the test look fluent, but I'm not sure if
the code is acceptable.
http://newtestbot.winehq.org/JobDetails.pl?Key=942
static void test_classesroot(void)
{
DWORD res, len, i;
HKEY hkey;
char name[32];
#define CREATE_KEY(key, path) \
{ \
HKEY tmp; \
if ((res = RegCreateKeyExA( key, path, 0, NULL, 0, \
KEY_ENUMERATE_SUB_KEYS|KEY_SET_VALUE|KEY_QUERY_VALUE|KEY_CREATE_SUB_KEY,
\
NULL, tmp, NULL )) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegCreateKeyExA %p\\%s failed with %08X\n, key,
path, res); \
return; \
} \
else \
{ \
RegCloseKey(tmp); \
} \
}
#define DELETE_KEY(key, path) \
{ \
DWORD res; \
if ((res = RegDeleteKey(key, path)) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegDeleteKey %p\\%s failed with %08X\n, key, path, res); \
return; \
} \
}
#define SET_VALUE(key, path, name, value) \
{ \
HKEY tmp; \
if ((res = RegOpenKeyExA( key, path, 0, \
KEY_SET_VALUE, tmp )) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegOpenKeyExA %p\\%s failed with %08X\n, key, path, res); \
return; \
} \
else \
{ \
if ((res = RegSetValueEx( tmp, name, 0, REG_SZ, \
(CONST BYTE*)value, strlen(value) ))
!= ERROR_SUCCESS) \
{ \
ok(FALSE, RegSetValueEx %p\\%s failed with %08X\n, tmp,
name, res); \
return; \
} \
RegCloseKey(tmp); \
} \
}
#define CHECK_EXIST_KEY(key, path) \
ok(exist_key(key, path), key %p\\%s should exist\n, key, path);
#define CHECK_NOT_EXIST_KEY(key, path) \
ok(!exist_key(key, path), key %p\\%s should exist\n, key, path);
#define CHECK_VALUE(key, path, name, value) \
{ \
HKEY tmp; \
if ((res = RegOpenKeyExA( key, path, 0, \
KEY_QUERY_VALUE, tmp )) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegOpenKeyExA %p\\%s failed with %08X\n, key, path, res); \
return; \
} \
else \
{ \
char buf[32]; \
DWORD type = REG_SZ, size = sizeof(buf); \
if ((res = RegQueryValueEx( tmp, name, 0, type, \
(BYTE*)buf, size )) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegQueryValueEx %p\\%s failed with %08X\n,
tmp, name, res); \
return; \
} \
ok(!strcmp(value, buf), %s expected '%s' but got '%s' in
%p\\%s\n, name, value, buf, key, path); \
RegCloseKey(tmp); \
} \
}
#define CHECK_NON_VALUE(key, path, name) \
{ \
HKEY tmp; \
if ((res = RegOpenKeyExA( key, path, 0, \
KEY_QUERY_VALUE, tmp )) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegOpenKeyExA %p\\%s failed with %08X\n, key, path, res); \
return; \
} \
else \
{ \
char buf[32]; \
DWORD type = REG_SZ, size = sizeof(buf); \
if ((res = RegQueryValueEx( tmp, name, 0, type, \
(BYTE*)buf, size )) == ERROR_SUCCESS) \
{ \
ok(FALSE, %s should not exist in %p\\%s\n, name, key, path); \
} \
else if (res != ERROR_FILE_NOT_FOUND) \
{ \
ok(FALSE, RegQueryValueEx %p\\%s failed with %08X\n,
tmp, name, res); \
return; \
} \
RegCloseKey(tmp); \
} \
}
#define DELETE_VALUE(key, path, name) \
{ \
HKEY tmp; \
if ((res = RegOpenKeyExA( key, path, 0, \
KEY_SET_VALUE, tmp )) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegOpenKeyExA %p\\%s failed with %08X\n, key, path, res); \
return; \
} \
else \
{ \
if ((res = RegDeleteValueA(tmp, name)) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegDeleteValue %s in %p\\%s failed with
%08X\n, name, key, path, res); \
return; \
} \
RegCloseKey(tmp); \
} \
}
#define CHECK_KEY_INFO(key, path, c1, c2) \
{ \
HKEY tmp; \
if ((res = RegOpenKeyExA( key, path, 0, \
KEY_QUERY_VALUE, tmp )) != ERROR_SUCCESS) \
{ \
ok(FALSE, RegOpenKeyExA %p\\%s failed with %08X\n, key, path, res); \
return; \
} \
else \
{ \
DWORD n1, n2; \
if (ERROR_SUCCESS != (res = RegQueryInfoKeyA( tmp, NULL, NULL, NULL, \
n1, NULL, NULL,
n2, NULL, NULL, NULL, NULL ))) \
{ \
ok(FALSE, RegQueryInfoKeyA failed with %08X\n\n, res); \
return; \
} \
ok(n1 == c1, subkey count
Re: shell32/tests: Fix a typo
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=7800 Your paranoid android. === W7PROX64 (64 bit shlexec) === shlexec.c:1738: Test failed: ShellExecuteEx(null, C:\Users\winetest\AppData\Local\Temp\wt9698.tmp\test file.sde, null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, C:\Users\winetest\AppData\Local\Temp\wt9698.tmp\test file.sde, null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, C:\Users\winetest\AppData\Local\Temp\wt9698.tmp\test file.sde, null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, C:\Users\winetest\AppData\Local\Temp\wt9698.tmp\test file.sde, null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, C:\Users\winetest\AppData\Local\Temp\wt9698.tmp\test file.sde, null, null) failed: rc=29 err=2
Re: [PATCH 1/5] ddraw/tests: Fix a typo.
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=7343 Your paranoid android. === W98SE (32 bit dsurface) === dsurface: unhandled exception c005 at 00415849
Re: [PATCH] inetcomm/smtptransport.c : Fix a typo ?
Hi Amine, Hi Juan, Um, it's called a prototype, and it's needed to compile smtptransport.c. Have you tested this patch at all? I knew it was a prototype, I just thought it was left over, as it wasn't at the top of the file, and I saw no other prototype in that file. As for testing, I was eventually going to re-compile, so I guess I'd figure this out later if you didn't mention it. Amine.
Re: [PATCH] inetcomm/smtptransport.c : Fix a typo ?
Hi Amine, -static void SMTPTransport_CallbackMessageSendTo(IInternetTransport *iface, char *pBuffer, int cbBuffer); - The actual function is a little bit under. Um, it's called a prototype, and it's needed to compile smtptransport.c. Have you tested this patch at all? --Juan
Re: [PATCH] inetcomm/smtptransport.c : Fix a typo ?
I knew it was a prototype, I just thought it was left over, as it wasn't at the top of the file, and I saw no other prototype in that file. As for testing, I was eventually going to re-compile, so I guess I'd figure this out later if you didn't mention it. We're not here to test your patches for you. C'mon, this should be obvious. --Juan
re: msvcrt: scanf fix a typo
On Sat, 20 Sep 2008, Michael Karcher wrote: [...] Looks like we need to compile with -fno-builtin-sscanf, because gcc knows the implementation of glibc's sscanf, and you explicitly have to forbid it to use this knowledge which does not apply perfectly to Microsofts sscanf. This (of course) is only applicable to those parts of wine that link to msvcrt and thus use msvcrt's scanf implementation. Just mentioning an alternative approach in case the -fno-builtin-* approach does not pan out: maybe we can fool gcc by doing something like this: char buf[3]; strcpy(buf, %P); ok( sscanf(1234, buf, ptr) == 1, sscanf failed\n ); -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY
Re: msvcrt: scanf fix a typo
On Mon, Sep 22, 2008 at 5:27 AM, Francois Gouget [EMAIL PROTECTED] wrote: On Sat, 20 Sep 2008, Michael Karcher wrote: [...] Looks like we need to compile with -fno-builtin-sscanf, because gcc knows the implementation of glibc's sscanf, and you explicitly have to forbid it to use this knowledge which does not apply perfectly to Microsofts sscanf. This (of course) is only applicable to those parts of wine that link to msvcrt and thus use msvcrt's scanf implementation. Just mentioning an alternative approach in case the -fno-builtin-* approach does not pan out: maybe we can fool gcc by doing something like this: char buf[3]; strcpy(buf, %P); ok( sscanf(1234, buf, ptr) == 1, sscanf failed\n ); -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY The fix Alexandre committed (http://source.winehq.org/git/wine.git/?a=commitdiff;h=6538cb44e371bcd3a821227ffc40624de5da1ead) fixed it for me (gcc version 3.4.6). -Austin
Re: msvcrt: scanf fix a typo
Michael Karcher [EMAIL PROTECTED] writes: OK. Thanks for the pointer. I have a configure test ready that checks whether the global -fno-builtin is really needed., and uses separate flags otherwise. I am planning to submit it in series with a second patch that checks for whether -fno-builtin-scanf is needed (check for warning on %P). I don't think there's any reason to make it that complex. You can just use -fno-builtin in all cases. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msvcrt: scanf fix a typo
Am Sonntag, den 21.09.2008, 11:25 +0200 schrieb Alexandre Julliard: Michael Karcher [EMAIL PROTECTED] writes: OK. Thanks for the pointer. I have a configure test ready that checks whether the global -fno-builtin is really needed., and uses separate flags otherwise. I am planning to submit it in series with a second patch that checks for whether -fno-builtin-scanf is needed (check for warning on %P). I don't think there's any reason to make it that complex. You can just use -fno-builtin in all cases. Sure I can, this was approach b I suggested. But that may be harmful to performance, as it forbids gcc to use any knowledge about the standard library (includes inlining of memcpy with small constant sizes or built-in pureness annotations). But the issue that started the discussion was: What to do about the scanf warning? On a system that does not have wchar builtins in gcc, currently all built-in functions are enabled. Even on these systems, we should disable the built-in scanf to prevent the warning in the scanf test. This need has long been unnoticed, as wchar ctype functions are built-in on our main development platform. Regards, Michael Karcher
Re: msvcrt: scanf fix a typo
Am Sonntag, den 21.09.2008, 13:07 +0200 schrieb Alexandre Julliard: Michael Karcher [EMAIL PROTECTED] writes: Sure I can, this was approach b I suggested. But that may be harmful to performance, as it forbids gcc to use any knowledge about the standard library (includes inlining of memcpy with small constant sizes or built-in pureness annotations). If performance is an issue you most likely don't want to use msvcrt at all, native Unix libc will always be faster. And knowing MS, they are capable of adding an exception handler in memcpy someday... I was thinking about our dll implementations. crtdll and msvcrtd both link to msvcrt. Looking at the implementations of these DLLs, it seems you are right. No need to not compile them with -fno-builtin. On the other hand, regedit, taskmgr, xcopy, wordpad and notepad are linked to msvcrt. Should that be changed? Regards, Michael Karcher
Re: msvcrt: scanf fix a typo
Michael Karcher [EMAIL PROTECTED] writes: Am Sonntag, den 21.09.2008, 13:07 +0200 schrieb Alexandre Julliard: If performance is an issue you most likely don't want to use msvcrt at all, native Unix libc will always be faster. And knowing MS, they are capable of adding an exception handler in memcpy someday... I was thinking about our dll implementations. crtdll and msvcrtd both link to msvcrt. Looking at the implementations of these DLLs, it seems you are right. No need to not compile them with -fno-builtin. That's not at all what I said. Any module that uses msvcrt headers needs to use -fno-builtin. On the other hand, regedit, taskmgr, xcopy, wordpad and notepad are linked to msvcrt. Should that be changed? No, they are just fine the way they are, and it provides some nice testing for our msvcrt. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msvcrt: scanf fix a typo
Am Sonntag, den 21.09.2008, 13:46 +0200 schrieb Alexandre Julliard: Michael Karcher [EMAIL PROTECTED] writes: Am Sonntag, den 21.09.2008, 13:07 +0200 schrieb Alexandre Julliard: If performance is an issue you most likely don't want to use msvcrt at all, native Unix libc will always be faster. I was thinking about our dll implementations. crtdll and msvcrtd both link to msvcrt. Looking at the implementations of these DLLs, it seems you are right. No need to not compile them with -fno-builtin. That's not at all what I said. Any module that uses msvcrt headers needs to use -fno-builtin. Sorry, I didn't manage to write what I mean. The only dll modules in the wine tree that currently use @BUILTINFLAG@ (and include msvcrt headers) are the two I listed. And after examing the little amount of C code they contain, I see no problem to compile them with -fno-builtin. That's what I meant to say. So your patch of always using -fno-builtin with gcc is the right way to go. Regards, Michael Karcher
Re: msvcrt: scanf fix a typo
Michael Karcher [EMAIL PROTECTED] writes: Sorry, I didn't manage to write what I mean. The only dll modules in the wine tree that currently use @BUILTINFLAG@ (and include msvcrt headers) are the two I listed. And after examing the little amount of C code they contain, I see no problem to compile them with -fno-builtin. Right; I agree we wouldn't want to use -fno-builtin in other dlls, but we don't want to use msvcrt in dlls anyway, and we should never need to. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msvcrt: scanf fix a typo
On Fri, Sep 19, 2008 at 03:51:00PM -0700, Dan Kegel wrote: Here's the gcc error: scanf.c:66: warning: unknown conversion type character `P' in format I'm not a programmer, but I play one on TV. And here's what I came up with in five minutes of typing and not enough thinking: That particular error depends on gcc knowing intimate details of sscanf. Unless we teach gcc about the particular sscanf we're implementing, it's likely to give false errors. For the tests, the compile time error can be avoided by using a non-constant format string. Quite possibly adding a global variable whose value is a always zero to the format string is enough. David -- David Laight: [EMAIL PROTECTED]
re: msvcrt: scanf fix a typo
Am Freitag, den 19.09.2008, 15:51 -0700 schrieb Dan Kegel: Here's the gcc error: scanf.c:66: warning: unknown conversion type character `P' in format That particular error depends on gcc knowing intimate details of sscanf. Unless we teach gcc about the particular sscanf we're implementing, it's likely to give false errors. See http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Function-Attributes.html#Function-Attributes for the function attributes used to teach gcc about scanf-like format arguments. Looks like we need to compile with -fno-builtin-sscanf, because gcc knows the implementation of glibc's sscanf, and you explicitly have to forbid it to use this knowledge which does not apply perfectly to Microsofts sscanf. This (of course) is only applicable to those parts of wine that link to msvcrt and thus use msvcrt's scanf implementation. Regards, Michael Karcher
re: msvcrt: scanf fix a typo
Am Samstag, den 20.09.2008, 10:50 +0200 schrieb Michael Karcher: Looks like we need to compile with -fno-builtin-sscanf, because gcc knows the implementation of glibc's sscanf, OK, I looked further into it. On Linux, we don't get the warning, because gcc is called with the sledgehammer option -fno-builtin for msvcrt related stuff (which includes *all* -fno-builtin-* options, so also -fno-builtin-sscanf) if gcc's builtin prototype for the wchar ctype function conflicts with int iswlower(unsigned short);. Probably on your system, your C library does not have these functions or your gcc is older than 4.0, so there are no builtin prototypes for the wchar stuff. There are some ways to fix it: a) Detect whether gcc recognizes scanf as builtin function, and enable -fno-builtin in that case too. This will trigger on gcc version 3.3 and up. b) Always pass -fno-builtin to msvcrt related stuff when compiling with gcc, i.e. drop the wchar test. c) Make the -fno-builtin option more specific. i.e. if wchar stuff conflicts with msvcrt, enable -fno-builtin-iswalnum -fno-builtin-iswalpha -fno-builtin-iswascii -fno-builtin-iswcntrl -fno-builtin-iswdigit -fno-builtin-iswgraph -fno-builtin-iswlower -fno-builtin-iswprint -fno-builtin_iswpunct -fno-builtin-iswspace -fno-builtin-iswupper -fno-builtin-iswxdigit -fno-builtin-towlower -fno-builtin-towupper and if scanf is detected, enable -fno-builtin-fscanf -fno-builtin-scanf -fno-builtin-sscanf The upside is that we don't lose gcc's checking of other standard C functions, while the downside is that the gcc command line in msvcrt related modules gets awfully long. These modules are: dlls/msvcrtd/tests dlls/msvcrtd dlls/msvcrt/tests dlls/crtdll (Just grep Makefile.in for @BUILTINCFLAG@) While the specific -fno-builtin-foo optins have been introduced in gcc 3.1, we do not need to check whether gcc is new enough, as these old versions of gcc have neither wchar nor sscanf functions built in. If wine-devel agrees to one approach, I am happy to submit a patch that implements this approach. I personally prefer a crossover between approach b and c. Approach a is out, because on recent versions of gcc, it is essentially approach b, but unnecessarily complicating the configure script. Also it tends to hide problems, just as it happened here. gcc has added a sanity check for sscanf parameters (which is a good thing, IMHO), but we never noticed it, because it got suppressed because of configure finding wchar builtins on the platform most Wine developers work on. With this approach, changing the platform might change gcc's behaviour on sscanf without anyone expecting it. Approach b is correct in the sense that the MS C library is not the platform C library, so gcc better does not assume anything about it, but that also might incur performance penalties, as things like memcpy with small constant size will never get inlined. Probably b really is what the wine project needs in the tests of msvcrt, as the goal is to test msvcrt and not gcc's inline code. For the tests, performance penalties do not matter. On the other hand, for the implementation side (msvcrtd and crtdll), option c seems attractive to me, because it just disables the stuff we need disabled but allows gcc to take full advantage about knowing the C standard on functions where msvcrt is not incompatible. A problem with option C is, that it is playing a cat-and-mouse game with the gcc developers: As soon as they add some more checks to calling standard library functions that are incompatible with Microsofts extensions, we start to get warnings again. Regards, Michael Karcher
Re: msvcrt: scanf fix a typo
Michael Karcher [EMAIL PROTECTED] writes: On the other hand, for the implementation side (msvcrtd and crtdll), option c seems attractive to me, because it just disables the stuff we need disabled but allows gcc to take full advantage about knowing the C standard on functions where msvcrt is not incompatible. A problem with option C is, that it is playing a cat-and-mouse game with the gcc developers: As soon as they add some more checks to calling standard library functions that are incompatible with Microsofts extensions, we start to get warnings again. The real problem is that the -fno-builtin-xxx option is broken on some gcc versions. We used to use it, but we had to switch to a global -fno-builtin because of this bug. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msvcrt: scanf fix a typo
On Samstag 20 September 2008, Paul Vriens wrote: James Hawkins wrote: On Fri, Sep 19, 2008 at 4:59 PM, Austin English [EMAIL PROTECTED] wrote: Relevant code: /* check %p with no hex digits */ ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); Comment reads %p. All the other chars are lower case, and you can see the values are different (1233 vs 1234). I'm still positive the original author meant to use capital P. There's no point in adding yet another test for a number that is different by one digit. I have to agree with James here. The original author (Peter Oberndorfer) added the tests and an implementation of %p and %P. Commits: 02fb99e6b360a6f321f716b57df97ca79ec1b9f3 9e3a4652dafbcf1f3f957858a54f2149e91942b7 It was my intention to test lower and upper case %p. I used different number to make sure this is the result of the current scanf call not from another call above with the same expected result. adding ptr = (void*)0xdeadbeef; before each test would have been more explicit. Greetings Peter
Re: msvcrt: scanf fix a typo
Am Samstag, den 20.09.2008, 12:17 +0200 schrieb Alexandre Julliard: The real problem is that the -fno-builtin-xxx option is broken on some gcc versions. We used to use it, but we had to switch to a global -fno-builtin because of this bug. OK. Thanks for the pointer. I have a configure test ready that checks whether the global -fno-builtin is really needed., and uses separate flags otherwise. I am planning to submit it in series with a second patch that checks for whether -fno-builtin-scanf is needed (check for warning on %P). Regards, Michael Karcher
Re: msvcrt: scanf fix a typo
On Fri, Sep 19, 2008 at 4:39 PM, Austin English [EMAIL PROTECTED] wrote: Found using -Werror (strangely, didn't occur on ubuntu, but does on PC-BSD)...Must be the gcc version. @@ -63,7 +63,7 @@ static void test_sscanf( void ) ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); -ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); +ok( sscanf(1234, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); How do you figure that's a typo? The test right above it is exactly the same as what you've changed this one to. I didn't write the test, but I'm pretty sure the original author meant to test both cases. This is a good reason why tests should be commented, so the author's intent is well known. -- James Hawkins
Re: msvcrt: scanf fix a typo
On Fri, Sep 19, 2008 at 4:51 PM, James Hawkins [EMAIL PROTECTED] wrote: On Fri, Sep 19, 2008 at 4:39 PM, Austin English [EMAIL PROTECTED] wrote: Found using -Werror (strangely, didn't occur on ubuntu, but does on PC-BSD)...Must be the gcc version. @@ -63,7 +63,7 @@ static void test_sscanf( void ) ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); -ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); +ok( sscanf(1234, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); How do you figure that's a typo? The test right above it is exactly the same as what you've changed this one to. I didn't write the test, but I'm pretty sure the original author meant to test both cases. This is a good reason why tests should be commented, so the author's intent is well known. -- James Hawkins Relevant code: /* check %p with no hex digits */ ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); Comment reads %p. All the other chars are lower case, and you can see the values are different (1233 vs 1234). -Austin
Re: msvcrt: scanf fix a typo
On Fri, Sep 19, 2008 at 4:59 PM, Austin English [EMAIL PROTECTED] wrote: Relevant code: /* check %p with no hex digits */ ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); Comment reads %p. All the other chars are lower case, and you can see the values are different (1233 vs 1234). I'm still positive the original author meant to use capital P. There's no point in adding yet another test for a number that is different by one digit. -- James Hawkins
Re: msvcrt: scanf fix a typo
Relevant code: /* check %p with no hex digits */ ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); Comment reads %p. All the other chars are lower case, and you can see the values are different (1233 vs 1234). That's not a compelling argument. For all we know, the test was intended to show that both %p and %P are interpreted the same way. --Juan
Re: msvcrt: scanf fix a typo
James Hawkins wrote: On Fri, Sep 19, 2008 at 4:59 PM, Austin English [EMAIL PROTECTED] wrote: Relevant code: /* check %p with no hex digits */ ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); Comment reads %p. All the other chars are lower case, and you can see the values are different (1233 vs 1234). I'm still positive the original author meant to use capital P. There's no point in adding yet another test for a number that is different by one digit. I have to agree with James here. The original author (Peter Oberndorfer) added the tests and an implementation of %p and %P. Commits: 02fb99e6b360a6f321f716b57df97ca79ec1b9f3 9e3a4652dafbcf1f3f957858a54f2149e91942b7 -- Cheers, Paul.
Re: msvcrt: scanf fix a typo
On Fri, Sep 19, 2008 at 6:14 PM, Paul Vriens [EMAIL PROTECTED] wrote: James Hawkins wrote: On Fri, Sep 19, 2008 at 4:59 PM, Austin English [EMAIL PROTECTED] wrote: Relevant code: /* check %p with no hex digits */ ok( sscanf(1233, %p, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1233,sscanf reads %p instead of %x\n, ptr, 0x1233 ); ok( sscanf(1234, %P, ptr) == 1, sscanf failed\n ); ok( ptr == (void *)0x1234,sscanf reads %p instead of %x\n, ptr, 0x1234 ); Comment reads %p. All the other chars are lower case, and you can see the values are different (1233 vs 1234). I'm still positive the original author meant to use capital P. There's no point in adding yet another test for a number that is different by one digit. I have to agree with James here. The original author (Peter Oberndorfer) added the tests and an implementation of %p and %P. Commits: 02fb99e6b360a6f321f716b57df97ca79ec1b9f3 9e3a4652dafbcf1f3f957858a54f2149e91942b7 -- Cheers, Paul. Here's the gcc error: gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -I/usr/local/include -Werror -o scanf.o scanf.c scanf.c: In function `test_sscanf': scanf.c:66: warning: unknown conversion type character `P' in format scanf.c:66: warning: too many arguments for format *** Error code 1 Stop in /usr/home/pcbsd/wine-git/dlls/msvcrt/tests.
re: msvcrt: scanf fix a typo
Here's the gcc error: scanf.c:66: warning: unknown conversion type character `P' in format I'm not a programmer, but I play one on TV. And here's what I came up with in five minutes of typing and not enough thinking: That particular error depends on gcc knowing intimate details of sscanf. Unless we teach gcc about the particular sscanf we're implementing, it's likely to give false errors. It could be that the line #include stdio.h at the top of that file is introducing a conflict. See http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Function-Attributes.html#Function-Attributes for the function attributes used to teach gcc about scanf-like format arguments. This may be an example of the problem Juan was anticipating, where people rush to provide fixes to problems that they don't fully understand, just to try to get rid of gcc warnings :-( - Dan
Re: msvcrt: scanf fix a typo
On Fri, Sep 19, 2008 at 5:51 PM, Dan Kegel [EMAIL PROTECTED] wrote: Here's the gcc error: scanf.c:66: warning: unknown conversion type character `P' in format I'm not a programmer, but I play one on TV. And here's what I came up with in five minutes of typing and not enough thinking: That particular error depends on gcc knowing intimate details of sscanf. Unless we teach gcc about the particular sscanf we're implementing, it's likely to give false errors. It could be that the line #include stdio.h at the top of that file is introducing a conflict. See http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Function-Attributes.html#Function-Attributes for the function attributes used to teach gcc about scanf-like format arguments. This may be an example of the problem Juan was anticipating, where people rush to provide fixes to problems that they don't fully understand, just to try to get rid of gcc warnings :-( - Dan Point taken. I'll just file a bug and let someone who knows what they're doing take a look at it. - Austin
[PATCH 3/3] user32: fix a typo. (resend)
Resending...
From c2921196f554dc317a8db2d6380fdcae10d23881 Mon Sep 17 00:00:00 2001
From: Lei Zhang [EMAIL PROTECTED]
Date: Wed, 9 Apr 2008 11:34:13 -0700
Subject: [PATCH 3/3] user32: fix a typo.
---
dlls/user32/edit.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/dlls/user32/edit.c b/dlls/user32/edit.c
index 7fd62cc..85de02e 100644
--- a/dlls/user32/edit.c
+++ b/dlls/user32/edit.c
@@ -855,10 +855,8 @@ static LRESULT WINAPI EditWndProc_common( HWND hwnd, UINT
msg,
if (charW == VK_RETURN || charW == VK_ESCAPE)
{
if (SendMessageW(GetParent(hwnd), CB_GETDROPPEDSTATE,
0, 0))
-{
SendMessageW(GetParent(hwnd), WM_KEYDOWN, charW,
0);
-break;
-}
+break;
}
}
result = EDIT_WM_Char(es, charW);
--
1.5.3.6
[1/5] basetsd.h: Fix a typo in the parameter name
Hi I think this patch is not correct. -#define LongToHandle(h) ((HANDLE)(LONG_PTR)(h)) +#define LongToHandle(h) ((HANDLE)(LONG_PTR)(l)) I dont see 'l' defined or sent to this macro any where. Thanks, VJ
Re: [1/5] basetsd.h: Fix a typo in the parameter name
On Wed, May 23, 2007 at 04:35:33PM +0900, Dmitry Timoshkov wrote: Hello, Changelog: basetsd.h: Fix a typo in the parameter name. --- include/basetsd.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/basetsd.h b/include/basetsd.h index e0d04f6..fe3639f 100644 --- a/include/basetsd.h +++ b/include/basetsd.h @@ -219,7 +219,7 @@ typedef unsigned short UHALF_PTR, *PUHALF_PTR; #define HandleToULong(h)((ULONG)(ULONG_PTR)(h)) #define HandleToLong(h) ((LONG)(LONG_PTR)(h)) #define ULongToHandle(ul) ((HANDLE)(ULONG_PTR)(ul)) -#define LongToHandle(h) ((HANDLE)(LONG_PTR)(h)) +#define LongToHandle(h) ((HANDLE)(LONG_PTR)(l)) I do not think this is right. Ciao, Marcus
Re: [1/5] basetsd.h: Fix a typo in the parameter name
Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: I think this patch is not correct. -#define LongToHandle(h) ((HANDLE)(LONG_PTR)(h)) +#define LongToHandle(h) ((HANDLE)(LONG_PTR)(l)) I dont see 'l' defined or sent to this macro any where. If you will inspect more closely all appropriate macros you will notice why it's a typo. -- Dmitry.
Re: [1/5] basetsd.h: Fix a typo in the parameter name
On Wed, May 23, 2007 at 05:04:39PM +0900, Dmitry Timoshkov wrote: Vijay Kiran Kamuju [EMAIL PROTECTED] wrote: I think this patch is not correct. -#define LongToHandle(h) ((HANDLE)(LONG_PTR)(h)) +#define LongToHandle(h) ((HANDLE)(LONG_PTR)(l)) I dont see 'l' defined or sent to this macro any where. If you will inspect more closely all appropriate macros you will notice why it's a typo. Well, I meant more that you should have changed h in both occurences, instead of just one. Like this: -#define LongToHandle(h) ((HANDLE)(LONG_PTR)(h)) +#define LongToHandle(l) ((HANDLE)(LONG_PTR)(l)) Ciao, Marcus
Re: [1/5] basetsd.h: Fix a typo in the parameter name
Marcus Meissner [EMAIL PROTECTED] wrote: -#define LongToHandle(h) ((HANDLE)(LONG_PTR)(h)) +#define LongToHandle(h) ((HANDLE)(LONG_PTR)(l)) I do not think this is right. Why? -- Dmitry.
Re: fix a typo
On Sa, 2007-01-06 at 15:08 +0100, Jonathan Ernst wrote: (I think) I decided to use options, because native Ports have: COM*: Multiple options (BaudRate, DataBits, StopBits, Parity) LPT*: A single option (TransmissionRetryTimeout) FILE: No options Wine will add Redirection, what we can set in the registry at HKCU\Software\Wine\Printing\Spooler\portname -- By by ... Detlef
Re: fix a typo
Le samedi 06 janvier 2007 à 21:39 +0100, Detlef Riekenberg a écrit : On Sa, 2007-01-06 at 15:08 +0100, Jonathan Ernst wrote: (I think) I decided to use options, because native Ports have: COM*: Multiple options (BaudRate, DataBits, StopBits, Parity) LPT*: A single option (TransmissionRetryTimeout) FILE: No options Wine will add Redirection, what we can set in the registry at HKCU\Software\Wine\Printing\Spooler\portname I did think it should be fixed because I thought that no was always followed by singular like in French (which seems logical but might be wrong in English). The patch was not based on technical ground. Regards.
Re: Fix a memory leak, fix a typo in the comment, add a trace
On Tue, Sep 19, 2006 at 11:44:52AM +0900, Dmitry Timoshkov wrote: please apply after Implement GetKerningPairs for TrueType fonts. Changelog: - fix a memory leak - fix a typo in the comment - add a trace about skipped a not supported kerning table format Hi Dmitry, Wouldn't it be nicer to simply resend the first patch again with these fixes applied? Thanks, Huw. -- Huw Davies [EMAIL PROTECTED]
Re: crypt32: fix a typo
All power to you :) I forgot to add the smiley, I meant it half-joking. I shouldn't reply to email late, ever :) Bad coder: more caffeine for you! --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: crypt32: fix a typo
On Mon, 2006-04-10 at 21:05 -0700, Juan Lang wrote:
-ret = CryptGetProvParam(hProv, PP_CONTAINER, (BYTE
*)szContainer,
-size, 0);
+ret = CryptGetProvParam(hProv, PP_CONTAINER,
+ (BYTE *)szContainer, size, 0);
if (ret)
{
len = MultiByteToWideChar(CP_ACP, 0, szContainer, -1,
@@ -761,7 +761,8 @@
if (szProvider)
{
-ret = CryptGetProvParam(hProv, PP_NAME, (BYTE *)szProvider,
size, 0);
+ret = CryptGetProvParam(hProv, PP_NAME, (BYTE *)szProvider,
+ size, 0);
if (ret)
Why ruin perfectly good formatting?
--
Dimi Paun [EMAIL PROTECTED]
Lattica, Inc.
Re: crypt32: fix a typo
Why ruin perfectly good formatting? This eliminates a line-wrap in my 80-col editor, and makes it consistent with the rest of the file, and indeed with the rest of the DLL. Plus, it's my file. --Juan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: crypt32: fix a typo
On Mon, 2006-04-10 at 22:28 -0700, Juan Lang wrote: Plus, it's my file. All power to you :) I forgot to add the smiley, I meant it half-joking. -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
