"Claudio Grondi" <[EMAIL PROTECTED]> wrote:
> but the problem with sets.c remains:
>
> C:\VisualC++NET2003\Vc7\bin\cl.exe /c /nologo /Ox /MD /W3 /G7 /GX
> /DNDEBUG -IE:\Python24\include -IE:\Python24\PC /Tcsrc/sets/sets.c
> /Fobuild\temp.win32-2.4\Re
> lease\src/sets/sets.obj
> sets.c
> src\sets\sets.c(68) : error C2099: initializer is not a constant
> src\sets\sets.c(68) : warning C4047: 'initializing' : 'PyTypeObject *'
> differs in levels of indirection from 'NyHeapDef_SizeGetter'
> src\sets\sets.c(69) : error C2099: initializer is not a constant
> src\sets\sets.c(69) : warning C4028: formal parameter 1 different from
> declaration
> src\sets\sets.c(70) : error C2099: initializer is not a constant
> src\sets\sets.c(70) : warning C4047: 'initializing' : 'PyTypeObject *'
> differs in levels of indirection from 'int (__cdecl *)(PyObject *)'
> src\sets\sets.c(70) : warning C4028: formal parameter 1 different from
> declaration
> src\sets\sets.c(70) : warning C4028: formal parameter 1 different from
> declaration
> error: command 'E:\VisualC++NET2003\Vc7\bin\cl.exe' failed with exit status
> 2
>
> The MSDN help gives a simple example of code raising compiler error C2099:
> // C2099.c
> int j;
> int *p;
> j = *p; // C2099, *p is not a constant
>
> The example code shows to me, that there is a good reason compiler
> generates an error in that case.
> j = *p; leads to an assignment of a random (and therefore maybe leading to a
> non deterministic crash of the executable during runtime) value to a
> variable, what can't be intended in a deterministic program.
This is confusing, because the problem of the example code is not that
*p is not constant but rather that p is undefined aka uninitialized.
Humm..
Compiling the following program:
#include <stdio.h>
int main(void) {
int j;
int *p;
j = *p;
printf("%d\n",j); /* Makes sure the optimizer doesnt remove the
previous code */
return 0;
}
with
gcc -O3 -Wall main.c
gives me:
main.c: In function `main':
main.c:4: warning: `p' might be used uninitialized in this function
(And I get a Segmentation fault from running the executable.)
The -Wall flag enables, umm, as it is saying 'all' warnings
though perhaps not really all, and this flag + others is used
by the compilation command generated by distutils when
building with gcc.
I don't see any warnings when building Guppy.
So there should be no case (as easy to discover) as that in the
example.
So I am confused.
I was beginning to wonder if we were talking about the same file/code.
This code is from sets.c lines 66..71
static NyHeapDef nysets_heapdefs[] = {
{0, &NyMutBitSet_Type, (NyHeapDef_SizeGetter) mutbitset_indisize},
{0, &NyCplBitSet_Type, 0, cplbitset_traverse},
{0, &NyNodeSet_Type, nodeset_indisize, nodeset_traverse,
nodeset_relate},
{0}
};
I can't see how there can be problems with initializers not being
constants here unless, perhaps if the compiler has a problem since
those functions (mutbitset_indisize etc) and the types that are used
as initializers are in separately compiled files. But gcc -Wall
-pedantic handles it and doesn't warn. I don't have the ANSI standard
but I have the 2nd edition of The C Programming Language by Kernighan
and Ritchie (1988, 'Based on Draft-Proposed ANSI C'), and it is saying
- quotes -
A8.7 Initialization
...
All the expressions in the initializer for a static object or array
must be constant expressions as described in &A7.19
...
A7.19 Constant Expressions
Syntactically, a constant expression is an expression restricted to a
subset of operators...
...
More latitude is permitted for the constant expressions of
initializers... Initializers must evaluate either to a constant or to
the address of a previously declared external or static object plus or
minus a constant.
- end quotes -
If this means the Microsoft .NET compiler is perhaps not compliant
with standard/ANSI C then since it was from 2003 maybe they have come
out with an update now that fixes this problem. I know, it may not
really help you because it may cost money, I don't know how long one
can get updates without paying. Alternatively, I think GCC is
available for Microsoft Windows although I don't know how it handles
the .NET architecture.
For me, if the case is according to hypothesis, and I would have to
rewrite the code to put all the functions and type objects in a single
file, it would be.. umm.. painful. (Though I could get around
it with #include trickery but it is still painful.)
Sverker
--
http://mail.python.org/mailman/listinfo/python-list
