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.
Here are the error messages:
c:\Projects\Gambit\gambc40b11\lib_num.c(52351): fatal error C1071: unexpected end of file found in comment
I believe the problem is expressed in line 44720 of _num.c. Here's that line:
___SET_F64(___F64V2,___F64DIV(___F64V1,___F64UNBOX(___GLO(53,___G__23__23_bignum_2e_inexact_2d_mdigit_2d_base))))
I think what's going on is the ___F64UNBOX() is returning a string that starts with '*' so the ___F64DIV expands to a string with '/*' in it.
Here's the definition of ___F64DIV:
#define ___F64DIV(x,y)(x/y)
Changing this to
#define ___F64DIV(x,y)(x/(y))
... eliminates the error. This same problem occurs in two other functions:
#define ___F64INV(x)1.0/x #define ___FIXINV(x)___FIX((___FIX(1)/x))
I added parens around the x's and it compiles now.
Great! I suspected something like this was going on and I'm glad you pinpointed the problem.
After running it, I got a console window and running some sort of command line program. I tried to define factorial and got this error when I typed the first ')':
Run-Time Check Failure #3 - The variable 'e' is being used without
being defined. line 2690 of os_tty.c
That line is at the end of this function:
lineeditor_output_terminal_op_move_abs
I changed the declaration of e (the unbound variable to be this:
___SCMOBJ e = ___FIX(___NO_ERR);
and it successfully ran (fact 1000). I haven't played with it further yet.
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:
Here are the error messages:
c:\Projects\Gambit\gambc40b11\lib_num.c(52351): fatal error C1071: unexpected end of file found in comment
I believe the problem is expressed in line 44720 of _num.c. Here's that line:
___SET_F64(___F64V2,___F64DIV(___F64V1,___F64UNBOX(___GLO(53,___G__23_ _23_bignum_2e_inexact_2d_mdigit_2d_base))))
I think what's going on is the ___F64UNBOX() is returning a string that starts with '*' so the ___F64DIV expands to a string with '/*' in it.
Here's the definition of ___F64DIV:
#define ___F64DIV(x,y)(x/y)
Changing this to
#define ___F64DIV(x,y)(x/(y))
... eliminates the error. This same problem occurs in two other functions:
#define ___F64INV(x)1.0/x #define ___FIXINV(x)___FIX((___FIX(1)/x))
I added parens around the x's and it compiles now.
Great! I suspected something like this was going on and I'm glad you pinpointed the problem.
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