Re: configure.ac: add -Werror to default compiler options
Dan Kegel [EMAIL PROTECTED] writes: On Thu, Sep 18, 2008 at 5:54 PM, Juan Lang [EMAIL PROTECTED] wrote: If a commit doesn't break on Alexandre's [and patchwatcher's] box, and it gets committed, but it does break on some other machine, what then? Who fixes it? I suppose the answer there is patchwatcher builds with multiple compilers and/or affected users with bum compilers turn off -Werror and/or we disable the errors that have high failure rates on some compilers. No, the answer is developers who really want their build to die on simple warnings can turn it on. We need Wine to build properly on a wide range of platforms and compiler versions, there's simply no way to ensure that the compile will always be warning free. It is very important that everybody be able to build Wine and give it a try, even non-developers. That's why I'm so strict about portable code, proper configure checks, and conservative makefiles. There's nothing worse than downloading a project you want to play with and find out you can't even compile it. A compile failure is a serious bug, and we should do everything possible to avoid them. Making -Werror the default is the worse thing we could do in that respect. -- Alexandre Julliard [EMAIL PROTECTED]
Re: winex11.drv: Make wglShareLists() cope with previously selected destination context (try 3)
First of all note that glXDestroyContext only destroys a context after no of the other threads is using it (it is in the specs of glXDestroyContext). Surely this means we've got to be doubly careful about keeping track of contexts that are current, otherwise we'd end up with WGL contexts backed by GLX contexts that aren't current in the thread they're supposed to be current in, and get hard-to-diagnose bugs. Second there are some more issues in wglShareLists which shouldn't get fixed in your patch but which I plan to fix at a later stage which you should take into account. Some BAD class of apps calls wglShareLists before making the source context current (so it isn't backed by a GLX context) while it has made the destination one current. In such case we need to perform a swap as right now such programs crash. OK. There's a patch floating about somewhere that swaps source and destination contexts for a couple of games that need it, I considered something along those lines but thought better of it. MSDN clearly mentions that the hglrc2 parameter shouldn't contain any existing display lists, so this situation isn't allowed. This would mean wglShareLists(dest, source) is invalid and second that when perform a legal wglShareLists(source, dest) that dest can't have been current in any thread. I took that statement from MSDN to imply that you can't have created any display lists glGenLists() in the destination context, but not say anything about having previously made it current in some thread. Does it imply that as well? Windows clearly allows it (or at least, allows the app to get away with doing it), or Windows apps wouldn't do it. Since wglShareLists is a tricky function which might require very ugly hacks I want to keep it as clean as possible. This means that you should write a small wine test case for the behavior of wglShareLists in the situation affected by your patch. Will do, thanks. jim
Re: winex11.drv: Make wglShareLists() cope with previously selected destination context (try 3)
Resending to the proper email address, this time.. On Friday 19 September 2008 06:37:03 am Jim Cameron wrote: MSDN clearly mentions that the hglrc2 parameter shouldn't contain any existing display lists, so this situation isn't allowed. This would mean wglShareLists(dest, source) is invalid and second that when perform a legal wglShareLists(source, dest) that dest can't have been current in any thread. I took that statement from MSDN to imply that you can't have created any display lists glGenLists() in the destination context, but not say anything about having previously made it current in some thread. Does it imply that as well? Windows clearly allows it (or at least, allows the app to get away with doing it), or Windows apps wouldn't do it. The referred to lists aren't display lists. It's more appropritely (specific sets of) resources.. eg. the list of valid textures, the list of valid shader objects, etc, are what's shared.
Re: winex11.drv: Make wglShareLists() cope with previously selected destination context (try 3)
Resending to the proper email address, this time.. And I likewise ;) (I was just thinking, I swear I hit Reply All...) The referred to lists aren't display lists. It's more appropritely (specific sets of) resources.. eg. the list of valid textures, the list of valid shader objects, etc, are what's shared. Ah. (Or should I say A?) I thought it might be something like that. It's not as if MSDN has ever been unclear in the past, or anything... jim
Re: configure.ac: add -Werror to default compiler options
On Fri, Sep 19, 2008 at 1:17 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: A compile failure is a serious bug, and we should do everything possible to avoid them. Agreed, to an extent. A user who is trying to compile with a really whacky toolchain (say, a C compiler on an Amiga, a mainframe, or a wristwatch) should expect some errors, and we should not try to avoid those if they reflect real problems that need to be solved before wine can run properly. And I also feel pretty strongly that compiler warnings have some value, and we should pay attention to them. Right now we're plugging our ears and going la la la la la I can't hear you, and that seems a bit careless. As Wine aims for higher and higher quality levels, eventually we will have to change our ways here. Making -Werror the default is the worse thing we could do in that respect. If we do it in the right way, it could end up increasing our code quality quite a bit without inconveniencing any users. The right way is to slowly fix all the warnings -- like Andrew Talbot is doing -- and slowly encourage all wine developers to crank up their warning levels to the max. Once we've voluntarily cleared out nearly all the warnings, we can then have a flag day to clean out all the rest, and switch -Werror on. That will keep errors from creeping back in.
Re: configure.ac: add -Werror to default compiler options
Dan Kegel [EMAIL PROTECTED] writes: Agreed, to an extent. A user who is trying to compile with a really whacky toolchain (say, a C compiler on an Amiga, a mainframe, or a wristwatch) should expect some errors, and we should not try to avoid those if they reflect real problems that need to be solved before wine can run properly. You don't need a wacky toolchain. All you need is a slightly old gcc, or a platform that not everybody has access to, like Mac OS. I periodically build on Mac OS and check for warnings, and there are always a few that creep in, like size_t printf formats. Do you really think Wine would be better off if it failed to build on Mac 90% of the time? Is printing a size_t with %d really so dangerous that it needs to break the build? And I also feel pretty strongly that compiler warnings have some value, and we should pay attention to them. Right now we're plugging our ears and going la la la la la I can't hear you, and that seems a bit careless. As Wine aims for higher and higher quality levels, eventually we will have to change our ways here. That's absolutely not true. We are trying very hard to avoid warnings, I don't commit patches that add warnings, and many people are sending fixes when they find warnings on their platform. That doesn't mean they should break the build. If we do it in the right way, it could end up increasing our code quality quite a bit without inconveniencing any users. It wouldn't make any difference to code quality, since we are already warnings-free on most standard builds. The right way is to slowly fix all the warnings -- like Andrew Talbot is doing -- and slowly encourage all wine developers to crank up their warning levels to the max. Once we've voluntarily cleared out nearly all the warnings, we can then have a flag day to clean out all the rest, and switch -Werror on. That will keep errors from creeping back in. Everybody is free to build their tree with -Werror, but there's no way that it will become the default. -- Alexandre Julliard [EMAIL PROTECTED]
Re: PrintDlgEx [1/7]: Add common failure checks and a trace.
Hi Gal, please bottom post here. I indeed submitted a set of tests that included these cases. Specifically: http://www.nabble.com/PrintDlgEx-tests--7-9-%3A-Add-tests-for-PD_RETURNDEFAULT.-td19293210.html#a19293210 http://www.nabble.com/PrintDlgEx-tests--9-9-%3A-Add-a-test-for-PD_RETURNDEFAULT-that-is-specific-to-PrintDlgExW.-td19293240.html#a19293240 Yes, and they weren't committed, perhaps because they don't pass without your implementation? I don't know, I didn't try. My point is, rather than including comments that say this and that behavior was tested on Windows version xyz, you should include test cases that demonstrate that, in one of two ways: 1. As a patch with tests that currently fails, each marked with todo_wine. 2. As a patch containing both implementation and tests. If you choose the first option, your implementation patch should remove the todo_wine from the (now succeeding) tests. --Juan
Re: [PATCH 4/7] d3dx9: Add a D3DXCreateTexture stub.
2008/9/19 Philip Nilsson [EMAIL PROTECTED]: +if (ret != D3D_OK) +return ret; + +return D3D_OK; This doesn't really make sense.
Re: [PATCH 7/7] d3dx9/tests: Test D3DXCreateTexture.
I think it would be a good idea to test the parameters (format, width, height, miplevels) of the created texture.
Re: [PATCH 6/7] d3dx9/tests: Test D3DXCheckTextureRequirements.
2008/9/19 Philip Nilsson [EMAIL PROTECTED]: This one could use some more work, but I think the tests will pass in most cases (except in strange environments without support for common formats). The tests should pass everywhere. I think you should be testing for consistency between CheckDeviceFormat() and D3DXCheckTextureRequirements().
Re: [PATCH 3/7] d3dx9: Implement D3DXCheckTextureRequirements.
2008/9/19 Philip Nilsson [EMAIL PROTECTED]:
+hr = IDirect3DDevice9_GetDirect3D(device, d3d9);
+if (hr != D3D_OK || !device)
+return D3DERR_INVALIDCALL;
+
+IDirect3D9_GetAdapterDisplayMode(d3d9, D3DADAPTER_DEFAULT, d3ddm);
+
+/* TODO: Use something more advanced that looks more like what's in
MSDN. */
+hr = IDirect3D9_CheckDeviceFormat(d3d9, D3DADAPTER_DEFAULT,
D3DDEVTYPE_HAL, d3ddm.Format, usage, D3DRTYPE_TEXTURE, *format);
You shouldn't guess the adapter, device type, etc., but use whatever
the device was created with. IDirect3DDevice9_GetCreationParameters()
should help there.
+if (hr != D3D_OK) {
+if (usage D3DUSAGE_DEPTHSTENCIL) {
+switch (*format) {
...
+}
+IDirect3D9_Release(d3d9);
+}
I'm not sure about the big switch statement there, but I do know that
just changing the format isn't enough. There's no guarantee the new
format will work, or if there is any format that will support that
specific set of usage flags at all.
Re: configure.ac: add -Werror to default compiler options
On Fri, Sep 19, 2008 at 04:35:45PM +0200, Alexandre Julliard wrote: Dan Kegel [EMAIL PROTECTED] writes: Agreed, to an extent. A user who is trying to compile with a really whacky toolchain (say, a C compiler on an Amiga, a mainframe, or a wristwatch) should expect some errors, and we should not try to avoid those if they reflect real problems that need to be solved before wine can run properly. You don't need a wacky toolchain. All you need is a slightly old gcc, or a platform that not everybody has access to, like Mac OS. I periodically Or a newer gcc, or -O3, or -D_FORTIFY_SOURCE=2 (default in SUSE and Redhat) etc etc. If someone wants -Werror, he can always set CFLAGS for himself ;) Ciao, Marcus
Re: [PATCH 3/7] d3dx9: Implement D3DXCheckTextureRequirements.
Hi!
On Fri, Sep 19, 2008 at 07:04:04PM +0200, Henri Verbeet wrote:
2008/9/19 Philip Nilsson [EMAIL PROTECTED]:
+hr = IDirect3DDevice9_GetDirect3D(device, d3d9);
+if (hr != D3D_OK || !device)
+return D3DERR_INVALIDCALL;
+
+IDirect3D9_GetAdapterDisplayMode(d3d9, D3DADAPTER_DEFAULT, d3ddm);
+
+/* TODO: Use something more advanced that looks more like what's
in MSDN. */
+hr = IDirect3D9_CheckDeviceFormat(d3d9, D3DADAPTER_DEFAULT,
D3DDEVTYPE_HAL, d3ddm.Format, usage, D3DRTYPE_TEXTURE, *format);
You shouldn't guess the adapter, device type, etc., but use whatever
the device was created with. IDirect3DDevice9_GetCreationParameters()
should help there.
Thanks, I didn't know there was a way. It doesn't matter in the test
though as I control the creation there, right?
+if (hr != D3D_OK) {
+if (usage D3DUSAGE_DEPTHSTENCIL) {
+switch (*format) {
...
+}
+IDirect3D9_Release(d3d9);
+}
I'm not sure about the big switch statement there, but I do know that
just changing the format isn't enough. There's no guarantee the new
format will work, or if there is any format that will support that
specific set of usage flags at all.
Yes, it doesn't take much for it to go wrong. It's basically just
correct for my settings.
A huge table containing the 12 different channels I know of might come
in handy. I'm not looking forward to filling it out though. (I do
however have some interesting ideas for the selection, so I'll do it as
soon as I can.)
Regards.
Re: configure.ac: add -Werror to default compiler options
OK, I just ran with -Wall -Werror, and got a grand total of four errors: freetype.c:1051: warning: 'name.string_len' is used uninitialized in this function Looks bogus. engine.c:2128: warning: 'str' may be used uninitialized in this function Bogus. context.c:80: warning: 'update_minfilter' may be used uninitialized in this function context.c:80: warning: 'update_magfilter' may be used uninitialized in this function Real! Looks like one slipped by yesterday: http://source.winehq.org/git/wine.git/?a=commitdiff;h=9533a5cbbf76cf4b9013ed90dd96e0f3995d44f3 That's not a bad haul. Now, if everyone were building with -O2 -Wall -Werror, that would have been caught sooner. But hey, if Alexandre doesn't like the idea, I guess it won't fly. So my alternate suggestion is for patchwatcher to reject patches that fail with -Werror. (And work around the couple of bogus errors I listed above.) That gets us the desired benefits without running into the problems Alexandre and Marcus pointed out. How's that sound? - Dan
Re: [PATCH 7/7] d3dx9/tests: Test D3DXCreateTexture.
On Fri, Sep 19, 2008 at 07:10:29PM +0200, Henri Verbeet wrote: I think it would be a good idea to test the parameters (format, width, height, miplevels) of the created texture. I used to do that, but most of the things you can check are just duplicates of the checks in D3DCheckTextureRequirements, and I think CreateTexture would fail if it couldn't fulfil the new requirements. I think the only thing that's left is format checking, but that's not very easy to check beyond general kind of format.
Re: [PATCH 6/7] d3dx9/tests: Test D3DXCheckTextureRequirements.
On Fri, Sep 19, 2008 at 07:07:18PM +0200, Henri Verbeet wrote: 2008/9/19 Philip Nilsson [EMAIL PROTECTED]: This one could use some more work, but I think the tests will pass in most cases (except in strange environments without support for common formats). The tests should pass everywhere. I agree, I'll add some more checks to make sure the tests will only be run if they can pass on the current setup (or find a set of parameters that will allow the tests to run). I think you should be testing for consistency between CheckDeviceFormat() and D3DXCheckTextureRequirements(). What do you mean?
Re: PrintDlgEx [2/7]: Add basic dialog.
On Do, 2008-09-18 at 09:58 +0200, Michael Stefaniuc wrote: there is no point in adding new resources in English to the other languages rc files. If a resource doesn't exist Win32 will automatically fail over to use the en_US version. According to julliard a while ago, this is not the case. Strings for sure will not fallback, when a group is present, but incomplete. (The last digit of the resource-id is the index in the group) For dialogs, I'm not sure, how large the group is. Actually its even detrimental to add the new resources as: a.) http://pf128.krakow.sdi.tpnet.pl/wine-transl/ cannot show those resources as untranslated. That's a known missing feature b.) The copied English resources have a tendency to bit-rot. That's a known risk. c.) The patch is smaller and offers the exact same functionality. Smaller: Yes Same functionality: Not always -- By by ... Detlef
WebKit vs Gecko and Wine
Hi, I have a nice idea to discuss at wineconf this year. Is it possible to use webkit for mshtml and jscript implementations of wine? Have been hearing a lotta good reviews about performance of webkit and lotta other browsers adopting it. How much work would it be to support webkit as to provide an alternative for winegecko? Firstly is it feasible. Thanks, VJ - Zsa Zsa Gabor - He taught me housekeeping; when I divorce I keep the house.
Re: winex11.drv: Make wglShareLists() cope with previously selected destination context (try 3)
Resending to the proper email address, this time.. And I likewise ;) (I was just thinking, I swear I hit Reply All...) The referred to lists aren't display lists. It's more appropritely (specific sets of) resources.. eg. the list of valid textures, the list of valid shader objects, etc, are what's shared. Ah. (Or should I say A?) I thought it might be something like that. It's not as if MSDN has ever been unclear in the past, or anything... jim That's the reason we need such tests .. I know it is a pain but bugs are much more complicated to debug in the end. Roderick -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Re: PrintDlgEx [2/7]: Add basic dialog.
Detlef Riekenberg wrote: On Do, 2008-09-18 at 09:58 +0200, Michael Stefaniuc wrote: there is no point in adding new resources in English to the other languages rc files. If a resource doesn't exist Win32 will automatically fail over to use the en_US version. According to julliard a while ago, this is not the case. Strings for sure will not fallback, when a group is present, but incomplete. (The last digit of the resource-id is the index in the group) For dialogs, I'm not sure, how large the group is. Dialogs are one resource. Stringtables are the oddballs as 16 strings form a resource. I was talking of adding new resources and explicitly not amending existing ones. And the patch was adding 2 new dialogs so there was no point of confusing Gal with the stringtables as those weren't part of the patch. Actually its even detrimental to add the new resources as: a.) http://pf128.krakow.sdi.tpnet.pl/wine-transl/ cannot show those resources as untranslated. That's a known missing feature A missing feature for which there is *no* complete solution. There are small resources with only 1-2 strings to translate. E.g. a lot of languages took over Ok. Now how do you decide if that is untranslated or if the translation happens to be the exact same as the en_US version? b.) The copied English resources have a tendency to bit-rot. That's a known risk. For no added benefit. I have thrown away such bit-rotted resources instead of fixing them and Alexandre accepted those patches. c.) The patch is smaller and offers the exact same functionality. Smaller: Yes Same functionality: Not always You are right; the smaller patch has always the better functionality. The stringtables being the exception here but that's why I recommended to use wrc with --verify-translation before and after the patch. If additional DIFF and ERR lines show up one knows that the other language resources need to be updated too. Else don't bother. bye michael
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
