http://bugs.winehq.com/show_bug.cgi?id=508
*** shadow/508 Sun Jun 9 11:50:13 2002
--- shadow/508.tmp.4845 Sun Jun 9 19:36:39 2002
***************
*** 33,35 ****
--- 33,47 ----
whole slew of traces to fix: %d -> %p.
IOW, lots of work to do.
+
+
+ ------- Additional Comments From fgouget(a)codeweavers.com 2002-06-09 19:36 -------
+ Some further elements of the plan: the plan is to first make progress on the
+ compilation errors by changing the code that uses HANDLES as indexes so that it
+ (hopefully) works in both STRICT and non-STRICT mode. To make it easier to work
+ the idea would be to further disable the %d/%p mismatch warning by disabling
+ them, by locally (i.e. not in CVS) redefining __WINE_PRINTF_ATTR in
+ 'include/wine/debug.h'.
+ Once Wine compiles with a void* HANDLE, then we can write a perl script that
+ parses the compilation log and automatically fixes the %d/%p warnings. Then
+ Alexandre can make one huge CVS commit.
http://bugs.winehq.com/show_bug.cgi?id=778
*** shadow/778 Sun Jun 9 15:24:39 2002
--- shadow/778.tmp.26524 Sun Jun 9 15:24:39 2002
***************
*** 0 ****
--- 1,50 ----
+ +============================================================================+
+ | Compiler warnings for wine-20020605 |
+ +----------------------------------------------------------------------------+
+ | Bug #: 778 Product: Wine |
+ | Status: UNCONFIRMED Version: unspecified |
+ | Resolution: Platform: |
+ | Severity: normal OS/Version: All |
+ | Priority: P1 Component: wine-binary |
+ +----------------------------------------------------------------------------+
+ | Assigned To: wine-bugs(a)winehq.com |
+ | Reported By: tenthumbs(a)cybernex.net |
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | Milestone: TargetMilestone: --- |
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ I used gcc -W and these warnigns turned up. Most of them are of the form
+ unsigned foo;
+ if (foo < 0) report _error;
+ Gcc is "smart" and knows unsigned values can never be negative so the test is
+ false, the error clause becomes unreachable code and gcc eliminates it when
+ optimizing. Not good.
+
+ I'm sure the component is wrong so someone fix it.
+
+ The list:
+ files/file.c:135: warning: unsigned value < 0 is always 0
+ dlls/ntdll/reg.c:229: warning: unsigned value < 0 is always 0
+ dlls/advapi32/crypt.c:845: warning: unsigned value < 0 is always 0
+ dlls/advapi32/crypt.c:1132: warning: unsigned value < 0 is always 0
+ dlls/gdi/freetype.c:712: warning: unsigned value < 0 is always 0
+ controls/button.c:201: warning: unsigned value < 0 is always 0
+ dlls/x11drv/winpos.c:1405: warning: unsigned value >= 0 is always 1
+ dlls/comctl32/listview.c:1835: warning: unsigned value >= 0 is always 1
+ dlls/comctl32/listview.c:1838: warning: unsigned value >= 0 is always 1
+ dlls/ole32/hglobalstream.c:614: warning: unsigned value < 0 is always 0
+ dlls/ole32/oleobj.c:291: warning: unsigned value < 0 is always 0
+ dlls/ole32/oleobj.c:650: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/ordinal.c:1163: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/ordinal.c:2458: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/ordinal.c:2473: warning: unsigned value < 0 is always 0
+ dlls/shlwapi/shlwapi_main.c:63: warning: unsigned value >= 0 is always 1
+ dlls/oleaut32/typelib.c:4586: warning: unsigned value >= 0 is always 1
+ dlls/oleaut32/typelib.c:4819: warning: unsigned value >= 0 is always 1
+ dlls/oleaut32/variant.c:3935: warning: unsigned value < 0 is always 0
+ dlls/oleaut32/variant.c:4035: warning: unsigned value < 0 is always 0
+ dlls/oleaut32/variant.c:4647: warning: unsigned value < 0 is always 0
+ dlls/wininet/internet.c:855: warning: unsigned value < 0 is always 0
+ dlls/wininet/internet.c:903: warning: unsigned value < 0 is always 0
\ No newline at end of file
http://bugs.winehq.com/show_bug.cgi?id=467
*** shadow/467 Sat Jun 1 17:18:34 2002
--- shadow/467.tmp.18617 Sun Jun 9 12:38:01 2002
***************
*** 301,303 ****
--- 301,307 ----
Ricardo can you try to install from CVS as we can work on the bug better if this
is the case.
+
+ ------- Additional Comments From centi_riccardo(a)libero.it 2002-06-09 12:38 -------
+ Created an attachment (id=171)
+ ME AGAIN
http://bugs.winehq.com/show_bug.cgi?id=508
*** shadow/508 Wed Mar 20 07:45:21 2002
--- shadow/508.tmp.16052 Sun Jun 9 11:50:13 2002
***************
*** 7,13 ****
| Severity: normal OS/Version: All |
| Priority: P1 Component: wine-winelib |
+----------------------------------------------------------------------------+
! | Assigned To: bugs(a)codeweavers.com |
| Reported By: fgouget(a)codeweavers.com |
| CC list: Cc: |
+----------------------------------------------------------------------------+
--- 7,13 ----
| Severity: normal OS/Version: All |
| Priority: P1 Component: wine-winelib |
+----------------------------------------------------------------------------+
! | Assigned To: wine-bugs(a)winehq.com |
| Reported By: fgouget(a)codeweavers.com |
| CC list: Cc: |
+----------------------------------------------------------------------------+
***************
*** 18,20 ****
--- 18,35 ----
| DESCRIPTION |
See bug 90 for instructions.
Approximate number of references: 1219
+
+ ------- Additional Comments From fgouget(a)codeweavers.com 2002-06-09 11:50 -------
+ This is the blocking target right now.
+ The problem is that many other handles are being assigned to a HANDLE variable.
+ So these assignements cannot be done without a cast as they otherwise generate a
+ warning.
+ So the idea is to convert HANDLE, and hence all other handle types to void*.
+ Thus assignments will be doable between them without casts. Then we can continue
+ converting individual handles to strict mode, i.e. to pointer types other than
+ void*.
+ There are a number of compilation errors to fix to make Wine compile with a
+ void* for handles: cases where a handle is used as an index. Then there is a
+ whole slew of traces to fix: %d -> %p.
+ IOW, lots of work to do.
+