[opensuse-programming] What's the best way to cure uninitialized variables?
Hi, I'm trying to build blender-2.49a for openSUSE Factory but it won't publish until I've cured uninitialized variables. My c++ skills are not that good. Could somebody have a look at http://bugzilla.novell.com/show_bug.cgi?id=525298 which has all the relevant information and give me a few pointers? Thanks in advance. Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Dave Plater wrote:
Hi, I'm trying to build blender-2.49a for openSUSE Factory but it won't publish until I've cured uninitialized variables. My c++ skills are not that good. Could somebody have a look at http://bugzilla.novell.com/show_bug.cgi?id=525298 which has all the relevant information and give me a few pointers?
Sure: *p, *q. To answer the question in the Subject line: initialize them. Jokes aside, I had a brief look at the source code, and unless I'm very mistaken the first two errors have to do with instantiation of btVector3. I think(!) the issue is in the 'tmp' variables - when they are instantiated, the m_floats array is uninitialized. I'm doing a build right now, I'll see what it says. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/07/2009 01:02 PM, Per Jessen wrote:
Dave Plater wrote:
Hi, I'm trying to build blender-2.49a for openSUSE Factory but it won't publish until I've cured uninitialized variables. My c++ skills are not that good. Could somebody have a look at http://bugzilla.novell.com/show_bug.cgi?id=525298 which has all the relevant information and give me a few pointers?
Sure: *p, *q.
To answer the question in the Subject line: initialize them.
Jokes aside, I had a brief look at the source code, and unless I'm very mistaken the first two errors have to do with instantiation of btVector3. I think(!) the issue is in the 'tmp' variables - when they are instantiated, the m_floats array is uninitialized.
I'm doing a build right now, I'll see what it says.
/Per Jessen, Zürich
Thanks Per, I should upload btVector3.h which I also suspected but it's quite a complicated array. The whole source is at home:plater:branches:graphics/blender if you have a build service account. Thanks Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/07/2009 01:02 PM, Per Jessen wrote:
Dave Plater wrote:
Hi, I'm trying to build blender-2.49a for openSUSE Factory but it won't publish until I've cured uninitialized variables. My c++ skills are not that good. Could somebody have a look at http://bugzilla.novell.com/show_bug.cgi?id=525298 which has all the relevant information and give me a few pointers?
Sure: *p, *q.
To answer the question in the Subject line: initialize them.
Jokes aside, I had a brief look at the source code, and unless I'm very mistaken the first two errors have to do with instantiation of btVector3. I think(!) the issue is in the 'tmp' variables - when they are instantiated, the m_floats array is uninitialized.
So if I initialize m_float in btVector3.h where I think it is declared, do you think it will solve at least one of the problems? I uploaded btVector3.h to bnc 525298 Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Dave Plater wrote:
So if I initialize m_float in btVector3.h where I think it is declared, do you think it will solve at least one of the problems?
Yes, that's what I was going to try. Probably in the default constructor. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/07/2009 04:37 PM, Per Jessen wrote:
Dave Plater wrote:
So if I initialize m_float in btVector3.h where I think it is declared, do you think it will solve at least one of the problems?
Yes, that's what I was going to try. Probably in the default constructor.
/Per Jessen, Zürich
The author of the program has used m_float in more than one instance, I tried initializing the one in btVector3 and got a compiler error, tried initializing the one in btSolverbody.h and it didn't make any difference. I think I might have bitten off more than I can chew but thats the best way to learn. Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Dave Plater wrote:
On 08/07/2009 04:37 PM, Per Jessen wrote:
Dave Plater wrote:
So if I initialize m_float in btVector3.h where I think it is declared, do you think it will solve at least one of the problems?
Yes, that's what I was going to try. Probably in the default constructor.
/Per Jessen, Zürich
The author of the program has used m_float in more than one instance, I tried initializing the one in btVector3 and got a compiler error, tried initializing the one in btSolverbody.h and it didn't make any difference. I think I might have bitten off more than I can chew but thats the best way to learn.
I couldn't get it whole thing to build, I ended up getting linker errors with a ton of symbols not found. In extern/bullet2/src/LinearMath/btVector3.h, try this: (line 65-66) /**@brief No initialization constructor */ SIMD_FORCE_INLINE btVector3() { m_floats[0]=m_floats[1]=m_floats[2]=m_floats[3]=btScalar(0.); } It compiles, but I don't know if it will solve the problem. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/08/2009 10:35 AM, Per Jessen wrote:
Dave Plater wrote:
On 08/07/2009 04:37 PM, Per Jessen wrote:
Dave Plater wrote:
So if I initialize m_float in btVector3.h where I think it is declared, do you think it will solve at least one of the problems?
Yes, that's what I was going to try. Probably in the default constructor.
/Per Jessen, Zürich
The author of the program has used m_float in more than one instance, I tried initializing the one in btVector3 and got a compiler error, tried initializing the one in btSolverbody.h and it didn't make any difference. I think I might have bitten off more than I can chew but thats the best way to learn.
I couldn't get it whole thing to build, I ended up getting linker errors with a ton of symbols not found.
In extern/bullet2/src/LinearMath/btVector3.h, try this: (line 65-66)
/**@brief No initialization constructor */ SIMD_FORCE_INLINE btVector3() { m_floats[0]=m_floats[1]=m_floats[2]=m_floats[3]=btScalar(0.); }
It compiles, but I don't know if it will solve the problem.
/Per Jessen, Zürich
I don't get the uninitialized variable warning in kdevelop3 at all for some reason, I'm using it to test build with all the flags setup the same as in the project spec file. For osc build I use quilt to patch. I will try your suggestion and report back. Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/08/2009 10:35 AM, Per Jessen wrote:
Dave Plater wrote:
On 08/07/2009 04:37 PM, Per Jessen wrote:
Dave Plater wrote:
So if I initialize m_float in btVector3.h where I think it is declared, do you think it will solve at least one of the problems?
Yes, that's what I was going to try. Probably in the default constructor.
/Per Jessen, Zürich
The author of the program has used m_float in more than one instance, I tried initializing the one in btVector3 and got a compiler error, tried initializing the one in btSolverbody.h and it didn't make any difference. I think I might have bitten off more than I can chew but thats the best way to learn.
I couldn't get it whole thing to build, I ended up getting linker errors with a ton of symbols not found.
In extern/bullet2/src/LinearMath/btVector3.h, try this: (line 65-66)
/**@brief No initialization constructor */ SIMD_FORCE_INLINE btVector3() { m_floats[0]=m_floats[1]=m_floats[2]=m_floats[3]=btScalar(0.); }
It compiles, but I don't know if it will solve the problem.
/Per Jessen, Zürich
It works! Now I'm left with :- I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. W: blender sequence-point source/gameengine/Physics/Bullet/CcdPhysicsController.cpp:1783, 1836 I: Program is using uninitialized variables. Note the difference between "is used" and "may be used" W: blender uninitialized-variable extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224 The btCylinderShape.cpp and btTriangleShapeEx.h unititialized variables have gone but is the undefined operation a result of the fix? Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Dave Plater wrote:
It works! Now I'm left with :- I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. W: blender sequence-point source/gameengine/Physics/Bullet/CcdPhysicsController.cpp:1783, 1836
Uh, I don't even have a line 1836 in that file?
I: Program is using uninitialized variables. Note the difference between "is used" and "may be used" W: blender uninitialized-variable extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224
Do you know who/what generates these warnings? They don't seem to be from g++.
The btCylinderShape.cpp and btTriangleShapeEx.h unititialized variables have gone but is the undefined operation a result of the fix?
I don't think so, but it is a bit suspect. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/08/2009 01:43 PM, Per Jessen wrote:
Dave Plater wrote:
It works! Now I'm left with :- I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. W: blender sequence-point source/gameengine/Physics/Bullet/CcdPhysicsController.cpp:1783, 1836
Uh, I don't even have a line 1836 in that file?
I: Program is using uninitialized variables. Note the difference between "is used" and "may be used" W: blender uninitialized-variable extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224
Do you know who/what generates these warnings? They don't seem to be from g++.
The btCylinderShape.cpp and btTriangleShapeEx.h unititialized variables have gone but is the undefined operation a result of the fix?
I don't think so, but it is a bit suspect.
/Per Jessen, Zürich
The warnings come from osc, I don't get these warnings when I build the same package using kdevelop3. I'm building for 11.1 to see if the same errors come up as factory. Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/08/2009 03:01 PM, Dave Plater wrote:
On 08/08/2009 01:43 PM, Per Jessen wrote:
Dave Plater wrote:
It works! Now I'm left with :- I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. W: blender sequence-point source/gameengine/Physics/Bullet/CcdPhysicsController.cpp:1783, 1836
Uh, I don't even have a line 1836 in that file?
blender-2.49/source/gameengine/Physics/Bullet/CcdPhysicsController.cpp Line 1836 = *poly_index_pt++ = *poly_index_pt++ = index[i]; Line 1783 = *poly_index_pt++ = *poly_index_pt++ = index[i];
I was using the svn version that's why you couldn't find it. I will revert back to the original. Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On Sat, 08 Aug 2009 15:58:59 +0200, you wrote:
blender-2.49/source/gameengine/Physics/Bullet/CcdPhysicsController.cpp Line 1836 = *poly_index_pt++ = *poly_index_pt++ = index[i]; Line 1783 = *poly_index_pt++ = *poly_index_pt++ = index[i];
I will revert back to the original.
no need for that :) AFAICT you just need to change both lines to *poly_index_pt = *(poly_index_pt+1) = index[i]; *poly_index_pt += 2; The compiler correctly complains because the outcome of the original operation is undefined as the compiler is free to choose the order in which to execute them as there are no sequence points which would order the operations. Therefore the programmer has to split such operations in a way that forces the compiler to do the operations exactly in the sequence the programmer had in mind. I've encountered such code more often then I would like but only after GCC began to complain about it. Philipp -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/08/2009 04:30 PM, Philipp Thomas wrote:
On Sat, 08 Aug 2009 15:58:59 +0200, you wrote:
blender-2.49/source/gameengine/Physics/Bullet/CcdPhysicsController.cpp Line 1836 = *poly_index_pt++ = *poly_index_pt++ = index[i]; Line 1783 = *poly_index_pt++ = *poly_index_pt++ = index[i];
I will revert back to the original.
no need for that :) AFAICT you just need to change both lines to
*poly_index_pt = *(poly_index_pt+1) = index[i]; *poly_index_pt += 2;
The compiler correctly complains because the outcome of the original operation is undefined as the compiler is free to choose the order in which to execute them as there are no sequence points which would order the operations. Therefore the programmer has to split such operations in a way that forces the compiler to do the operations exactly in the sequence the programmer had in mind.
I've encountered such code more often then I would like but only after GCC began to complain about it.
Philipp
Thanks Philipp, I will try that but it seems Per's solution works on the stable blender-2.49, it's completed building with only the last unitialized variable left to sort out :- W: blender uninitialized-variable extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224 Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Dave Plater wrote:
Thanks Philipp, I will try that but it seems Per's solution works on the stable blender-2.49, it's completed building with only the last unitialized variable left to sort out :- W: blender uninitialized-variable extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224
This is a wild guess: in line 224, try this: new ( &m_data[size()] ) T(_Val); /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/08/2009 04:56 PM, Per Jessen wrote:
Dave Plater wrote:
Thanks Philipp, I will try that but it seems Per's solution works on the stable blender-2.49, it's completed building with only the last unitialized variable left to sort out :- W: blender uninitialized-variable extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224
This is a wild guess: in line 224, try this:
new ( &m_data[size()] ) T(_Val);
/Per Jessen, Zürich
Hi Per, no it doesn't work. I've attached the details of the last remaining uninitialized variable (I'm using the release version), I will appreciate any input and meanwhile I'll keep trying myself. Thanks Dave P
On 08/08/2009 04:56 PM, Per Jessen wrote:
Dave Plater wrote:
Thanks Philipp, I will try that but it seems Per's solution works on the stable blender-2.49, it's completed building with only the last unitialized variable left to sort out :- W: blender uninitialized-variable extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224
This is a wild guess: in line 224, try this:
new ( &m_data[size()] ) T(_Val);
/Per Jessen, Zürich
I'm still stuck on :- /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h: In member function 'virtual void btOptimizedBvh::build(btStridingMeshInterface*, bool, const btVector3&, const btVector3&)::NodeTriangleCallback::internalProcessTriangleIndex(btVector3*, int, int)': /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224: warning: 'node.btOptimizedBvhNode::m_padding[4u]' is used uninitialized in this function /home/davepl/src/blender-2.49/extern/bullet2/src/BulletCollision/CollisionShapes/btOptimizedBvh.cpp:56: note: 'node.btOptimizedBvhNode::m_padding[4u]' was declared here /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224: warning: 'node.btOptimizedBvhNode::m_padding[3u]' is used uninitialized in this function /home/davepl/src/blender-2.49/extern/bullet2/src/BulletCollision/CollisionShapes/btOptimizedBvh.cpp:56: note: 'node.btOptimizedBvhNode::m_padding[3u]' was declared here /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224: warning: 'node.btOptimizedBvhNode::m_padding[2u]' is used uninitialized in this function /home/davepl/src/blender-2.49/extern/bullet2/src/BulletCollision/CollisionShapes/btOptimizedBvh.cpp:56: note: 'node.btOptimizedBvhNode::m_padding[2u]' was declared here /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224: warning: 'node.btOptimizedBvhNode::m_padding[1u]' is used uninitialized in this function /home/davepl/src/blender-2.49/extern/bullet2/src/BulletCollision/CollisionShapes/btOptimizedBvh.cpp:56: note: 'node.btOptimizedBvhNode::m_padding[1u]' was declared here /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224: warning: 'node.btOptimizedBvhNode::m_padding[0u]' is used uninitialized in this function /home/davepl/src/blender-2.49/extern/bullet2/src/BulletCollision/CollisionShapes/btOptimizedBvh.cpp:56: note: 'node.btOptimizedBvhNode::m_padding[0u]' was declared here To get the correct uninitialized variable message you need to pass gcc the following switches:- * -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 Any help appreciated. Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Dave Plater wrote:
On 08/08/2009 0 I'm still stuck on :- /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h: In member function 'virtual void btOptimizedBvh::build(btStridingMeshInterface*, bool, const btVector3&, const
btVector3&)::NodeTriangleCallback::internalProcessTriangleIndex(btVector3*,
int, int)': /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224: warning: 'node.btOptimizedBvhNode::m_padding[4u]' is used uninitialized in this function
Hmm, I think I know what's going on: the templated class btAlignedObjectArray has a method push_back(), which in line 224 uses new() in-place to initialize with the contents of argument _Val. I'm guessing that _Val is of type btOptimizedBvhNode, the struct with m_padding[5]. To copy from _Val to the new object, m_padding will also be read, but since it hasn't been initialized ... Try this in extern/bullet2/src/BulletCollision/BroadphaseCollision/btQuantizedBvh.h line 97: instead of "int m_padding[5]" : "int :5*8*sizeof(int)" I think that compiles, but does give a warning about the width of anynomous being wider than the type. If that causes a problem, try this instead: "int :sizeof(int)" "int :sizeof(int)" "int :sizeof(int)" "int :sizeof(int)" "int :sizeof(int)" /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/13/2009 12:36 PM, Per Jessen wrote:
Dave Plater wrote:
On 08/08/2009 0 I'm still stuck on :- /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h: In member function 'virtual void btOptimizedBvh::build(btStridingMeshInterface*, bool, const btVector3&, const
btVector3&)::NodeTriangleCallback::internalProcessTriangleIndex(btVector3*,
int, int)': /home/davepl/src/blender-2.49/extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224: warning: 'node.btOptimizedBvhNode::m_padding[4u]' is used uninitialized in this function
Hmm, I think I know what's going on:
the templated class btAlignedObjectArray has a method push_back(), which in line 224 uses new() in-place to initialize with the contents of argument _Val. I'm guessing that _Val is of type btOptimizedBvhNode, the struct with m_padding[5]. To copy from _Val to the new object, m_padding will also be read, but since it hasn't been initialized ...
Try this in
extern/bullet2/src/BulletCollision/BroadphaseCollision/btQuantizedBvh.h
line 97: instead of "int m_padding[5]" :
"int :5*8*sizeof(int)"
Your solution takes away the uninitialized variable I'll let you know if it works. Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
* Per Jessen (per@computer.org) [20090813 12:37]:
argument _Val. I'm guessing that _Val is of type btOptimizedBvhNode, the struct with m_padding[5]. To copy from _Val to the new object, m_padding will also be read, but since it hasn't been initialized ...
And? Where's the problem ? Simply initialize m_padding and the compiler will stop complaining. No need for the sizeof hack. Philipp -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Philipp Thomas wrote:
* Per Jessen (per@computer.org) [20090813 12:37]:
argument _Val. I'm guessing that _Val is of type btOptimizedBvhNode, the struct with m_padding[5]. To copy from _Val to the new object, m_padding will also be read, but since it hasn't been initialized ...
And? Where's the problem ? Simply initialize m_padding and the compiler will stop complaining. No need for the sizeof hack.
Philipp
btOptimizedBvhNode is a struct so you can't initialize where it is defined, only when it is instantiated. Making the padding anynomous is much easier (and there's no "hack" in using sizeof() to make sure I get the right number of bits). /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
* Per Jessen (per@computer.org) [20090813 18:23]:
btOptimizedBvhNode is a struct so you can't initialize where it is defined, only when it is instantiated.
Yes, because a struct doesn't have ctors you can't initialize it where defined, I know that. What I had in mind was initializing with memset(xxx,'\0', sizeof(xxx)).
Making the padding anynomous is much easier (and there's no "hack" in using sizeof() to make sure I get the right number of bits).
After thinking a bit about it, I guess you are right. And calling it hack wasn't right either, it was just that no other suitable term came to my mind. Philipp -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Philipp Thomas wrote:
* Per Jessen (per@computer.org) [20090813 18:23]:
btOptimizedBvhNode is a struct so you can't initialize where it is defined, only when it is instantiated.
Yes, because a struct doesn't have ctors you can't initialize it where defined, I know that. What I had in mind was initializing with memset(xxx,'\0', sizeof(xxx)).
Yeah, or just "struct btOptimizedBvhNode tmp = {0}", but I'm sure you see the problem - it has to be done wherever the thing is declared, and that's too much work.
Making the padding anynomous is much easier (and there's no "hack" in using sizeof() to make sure I get the right number of bits).
After thinking a bit about it, I guess you are right. And calling it hack wasn't right either, it was just that no other suitable term came to my mind.
I don't know what else to do to achieve the alignment the author wanted. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/13/2009 06:22 PM, Per Jessen wrote:
Philipp Thomas wrote:
* Per Jessen (per@computer.org) [20090813 12:37]:
argument _Val. I'm guessing that _Val is of type btOptimizedBvhNode, the struct with m_padding[5]. To copy from _Val to the new object, m_padding will also be read, but since it hasn't been initialized ...
And? Where's the problem ? Simply initialize m_padding and the compiler will stop complaining. No need for the sizeof hack.
Philipp
btOptimizedBvhNode is a struct so you can't initialize where it is defined, only when it is instantiated. Making the padding anynomous is much easier (and there's no "hack" in using sizeof() to make sure I get the right number of bits).
/Per Jessen, Zürich
I spent quite a while trying to initialize it where it is defined and found it impossible (not that I know that much but it's good to learn these things ) to either transfer &m_data to another variable or even use it due to the reference operator & mostly giving an lvalue error and I don't quite understand it yet. From what I can understand m_padding is simply extra memory in case of overflow. Thanks very much for your help Per and Philip, the package builds on local osc and works on my machine but I still have quite a few spec file problems to sort out before it will build online meanwhile I will submit the patch to blender.org devs to see if any unforeseen dangers may have been created. Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
Dave Plater wrote:
From what I can understand m_padding is simply extra memory in case of overflow.
I think it's more likely to be a filler to make sure the struct always has a certain size - for boundary alignment, optimized access or some such. Many instructions (SSEx for instance) require that data structures are on certain boundaries.
Thanks very much for your help Per and Philip, the package builds on local osc and works on my machine but I still have quite a few spec file problems to sort out before it will build online meanwhile I will submit the patch to blender.org devs to see if any unforeseen dangers may have been created.
Let us know how it goes. /Per Jessen, Zürich -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/14/2009 08:55 AM, Per Jessen wrote:
Dave Plater wrote:
From what I can understand m_padding is simply extra memory in case of overflow.
I think it's more likely to be a filler to make sure the struct always has a certain size - for boundary alignment, optimized access or some such. Many instructions (SSEx for instance) require that data structures are on certain boundaries.
Thanks very much for your help Per and Philip, the package builds on local osc and works on my machine but I still have quite a few spec file problems to sort out before it will build online meanwhile I will submit the patch to blender.org devs to see if any unforeseen dangers may have been created.
Let us know how it goes.
/Per Jessen, Zürich
The package builds at last for 11.1, factory snapshot and staging. Repositories :- http://download.opensuse.org/repositories/home:plater:branches:graphics/snap... http://download.opensuse.org/repositories/home:plater:branches:graphics/stag... http://download.opensuse.org/repositories/home:plater:branches:graphics/open... I haven't fixed up the changelogs etc. yet. Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On Sat, 08 Aug 2009 15:01:42 +0200, you wrote:
The warnings come from osc, I don't get these warnings when I build the same package using kdevelop3.
The warnings definitely come from the compiler when passed the right Options, which is mainly -Wall! But as they are only warnings the compiler will succeed in compiling. OSC scans the comipler output and turns some warnings into fatal errors because the past has shown us that these lead to broken programs. If you carefully log the compiler output[1] and scan it afterwards you'll see all those warnings the compiler produced. Philipp 1) My favourite for logging when not using 'osc build' is is defining a simple shell function mk() { make "$@" 2>&1 | tee mlog; }. Now you simply call mk (possibly whith additional options for make) and afterwards have a complete log. -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/08/2009 04:11 PM, Philipp Thomas wrote:
On Sat, 08 Aug 2009 15:01:42 +0200, you wrote:
The warnings come from osc, I don't get these warnings when I build the same package using kdevelop3.
The warnings definitely come from the compiler when passed the right Options, which is mainly -Wall! But as they are only warnings the compiler will succeed in compiling. OSC scans the comipler output and turns some warnings into fatal errors because the past has shown us that these lead to broken programs.
If you carefully log the compiler output[1] and scan it afterwards you'll see all those warnings the compiler produced.
Philipp
1) My favourite for logging when not using 'osc build' is is defining a simple shell function mk() { make "$@" 2>&1 | tee mlog; }. Now you simply call mk (possibly whith additional options for make) and afterwards have a complete log.
Well I must admit I feel like an idiot, I was setting C flags in cmake and not the CXX flags (at least I'll never make the same mistake). I can now get the exact same messages to display in kdevelop3 as I receive from osc, without the summary of course. Thanks very much for your patience with me. Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
On 08/08/2009 01:43 PM, Per Jessen wrote:
Dave Plater wrote:
It works! Now I'm left with :- I: Program causes undefined operation (likely same variable used twiceand post/pre incremented in the same expression). e.g. x = x++; Split it in two operations. W: blender sequence-point source/gameengine/Physics/Bullet/CcdPhysicsController.cpp:1783, 1836
Uh, I don't even have a line 1836 in that file?
I: Program is using uninitialized variables. Note the difference between "is used" and "may be used" W: blender uninitialized-variable extern/bullet2/src/LinearMath/btAlignedObjectArray.h:224
Do you know who/what generates these warnings? They don't seem to be from g++.
The btCylinderShape.cpp and btTriangleShapeEx.h unititialized variables have gone but is the undefined operation a result of the fix?
I don't think so, but it is a bit suspect.
/Per Jessen, Zürich
Am I correct in assuming that the following snippet "int m_padding[5];//bad, due to alignment" from blender-2.49/extern/bullet2/src/BulletCollision/BroadphaseCollision/btQuantizedBvh.h is the cause of the last uninitialized variable? :- /// btOptimizedBvhNode contains both internal and leaf node information. /// Total node size is 44 bytes / node. You can use the compressed version of 16 bytes. ATTRIBUTE_ALIGNED16 (struct) btOptimizedBvhNode { BT_DECLARE_ALIGNED_ALLOCATOR(); //32 bytes btVector3 m_aabbMinOrg; btVector3 m_aabbMaxOrg; //4 int m_escapeIndex; //8 //for child nodes int m_subPart; int m_triangleIndex; int m_padding[5];//bad, due to alignment }; Regards Dave P -- To unsubscribe, e-mail: opensuse-programming+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming+help@opensuse.org
participants (4)
-
Dave Plater -
Per Jessen -
Philipp Thomas -
Philipp Thomas