Could you send me a list of the warnings? I have already fixed a bunch of coercion problems between beta 10 and beta 11.
Great! I suspected something like this was going on and I'm glad you pinpointed the problem.
Nice catch. Which version of MS VC are you using? Did you use any special options to get these error checks?
Is there a test suite?
Try "make check". You may have to install MinGW to get make. Otherwise look at tests/makefile and do the steps manually.
Marc
Afficher les réponses par date
At 09:34 PM 10/25/2004, Marc Feeley wrote:
Which version of MS VC are you using? Did you use any special options to get these error checks?
I'm using Visual Studio.NET 2003, version 7.1.30088. I didn't use anything special to get the runtime check. (I'm not a VS.NET guru. I did look for something that would
> I tried this again under VS.NET 2003. Again, building a project with > lib*.c and gsi*.c, > adding <gambit>\include to the include paths. I also suppressed a few > warnings related to coercions.
Could you send me a list of the warnings? I have already fixed a bunch of coercion problems between beta 10 and beta 11.
I put some of them at the end of this message. I stopped suppressing warnings and had 43K lines of messages before I gave up. (Visual Studio was getting slower and slower just trying to insert the warnings into one of its windows.) 8^)
> Is there a test suite?
Try "make check". You may have to install MinGW to get make. Otherwise look at tests/makefile and do the steps manually.
I will when I get a chance later in the week.
There are only 7 distinct kinds of warnings in the 1st 10K lines of compiler output. Here are the 1st lines of each type plus VS.NET's description of each.
c:\Projects\Gambit\gambc40b11\gsi_gsi.c(956) : warning C4101: '___temp' : unreferenced local variable
Visual C++ Concepts: Building a C/C++ Program
Compiler Warning (level 3) C4101'identifier' : unreferenced local variable
The local variable is never used. This warning will occur in the obvious situation:
// C4101a.cpp // compile with: /W3 int main() { int i; // C4101 }
However, this warning will also occur when calling a static member function through an instance of the class:
// C4101b.cpp // compile with: /W3 struct S { static int func() { return 1; } };
int main() { S si; // C4101, si is never used int y = si.func(); return y; }
In this situation, the compiler uses information about si to access the static function, but the instance of the class is not needed to call the static function; hence the warning. To resolve this warning, you could:
Add a constructor, in which the compiler would use the instance of si in the call to func. Remove the static keyword from the definition of func.
Call the static function explicitly: int y = S::func();.
--------------------------------------------------------------------------------
c:\Projects\Gambit\gambc40b11\gsi_gsi.c(968) : warning C4102: '___L1__20___gsi' : unreferenced label
Visual C++ Concepts: Building a C/C++ Program
Compiler Warning (level 3) C4102'label' : unreferenced label
The label is defined but never referenced. The compiler ignores the label. The following sample generates C4102:
// C4102.cpp // compile with: /W3 int main() { int a;
test: // C4102, remove the unreferenced label to resolve
a = 1; }
--------------------------------------------------------------------------------
c:\Projects\Gambit\gambc40b11\lib\os_tty.c(7249) : warning C4113: 'BOOL (__stdcall *)()' differs in parameter lists from 'PHANDLER_ROUTINE'
Visual C++ Concepts: Building a C/C++ Program
Compiler Warning (level 1) C4113'identifier1' differs in parameter lists from 'identifier2'
A function pointer is assigned to another function pointer, but the formal parameter lists of the functions do not agree. The assignment is compiled without modification.
--------------------------------------------------------------------------------
c:\Projects\Gambit\gambc40b11\lib\os_tty.c(7031) : warning C4244: 'initializing' : conversion from 'double' to 'int', possible loss of data
Visual C++ Concepts: Building a C/C++ Program
Compiler Warning (level 1) C4244'variable' : conversion from 'type' to 'type', possible loss of data
You assigned a value of type __int64 to a variable of type unsigned int. A possible loss of data may have occurred.
C4244 can also fire at levels 3 and 4; see Compiler Warning (levels 3 and 4) C4244 for more information.
--------------------------------------------------------------------------------
c:\Projects\Gambit\gambc40b11\lib\os_time.c(234) : warning C4307: '*' : integral constant overflow
Visual C++ Concepts: Building a C/C++ Program
Compiler Warning (level 2) C4307'operator' : integral constant overflow
The operator is used in an expression that results in an integer constant overflowing the space allocated for it. You may need to use a larger type for the constant. A signed int holds a smaller value than an unsigned int because the signed int uses one bit to represent the sign.
The following sample generates C4307:
// C4307.cpp // compile with: /W2 int i = 2000000000 + 2000000000; // C4307 int j = (unsigned)2000000000 + 2000000000; // OK
int main() { }
--------------------------------------------------------------------------------
c:\Projects\Gambit\gambc40b11\gsi_gsi.c(1111) : warning C4311: 'type cast' : pointer truncation from 'int *' to 'int'
Visual C++ Concepts: Building a C/C++ Program
Compiler Warning (level 1) C4311'variable' : pointer truncation from 'type' to 'type'
A 64-bit pointer was truncated to a 32-bit int or 32-bit long.
--------------------------------------------------------------------------------
c:\Projects\Gambit\gambc40b11\gsi_gsi.c(1116) : warning C4312: 'type cast' : conversion from 'int' to '___label_struct *' of greater size
Visual C++ Concepts: Building a C/C++ Program
Compiler Warning (level 1) C4312'variable' : conversion from 'type' to 'type' of greater size
You attempted to assign a 32-bit value to a 64-bit integer. For example, casting a 32-bit int or 32-bit long to a 64-bit pointer.
--------------------------------------------------------------------------------
I'd prefer to look at representative samples since most of the warnings repeat *many* times, but having a fuller listing may help. I'll send you the 1st 10K warnings in a separate post (not to the whole group).
- Mark
On Monday, October 25, 2004, at 11:34 PM, Marc Feeley wrote:
Isn't the invariant supposed to be that each macro is supposed to return a fully parenthesized expression, so that you should change ___F64UNBOX rather than ___F64DIV?
And what is ___FIXINV supposed to do? The only definition or use in the entire Gambit source tree of ___FIXINV is a definition in gambit.h, so I think it should just be removed from gambit.h.
Brad