Sign in to follow this  
  • entries
  • comments
  • views

Debugging and compiler errors

Sign in to follow this  


It's not very often I get to say this, but I think I've found a compiler bug in VC8.0 SP1; Well, maybe not a 'bug' but certainly something I didn't expect...

int createTexture(GTL::ImagePtr tex)
const bool texurePowerOfTwo = isImagePowerTwo(tex);
const bool hasGL2 = GLEE_VERSION_2_0;
const bool hasNPOT = GLEE_ARB_texture_non_power_of_two;

if(!texurePowerOfTwo && (!hasGL2 && !hasNPOT))
return 0; // NPOT textures supported on GL2.0 and later as well as hardware which shows the extension

GLuint texture;

// the following statesments are here to show how the rest of the code looks
if (a)
// do stuff with no return statement
else if(b)
// do other stuff with no return statement
else if(c)
// do other other stuff with no return statement

Now, the function this comes from is long, thus the short version above, however there is one fundimental error; under normal operation it doesn't work right.

Near the top we have the check to see if we can handle certain combinations of texture data and GL extensions/caps, if we can't we return 0. If we can however the rest of the code is then run and the function just drops out of the bottom with the final return value being whatever happens to be in the return register.

Now, I expected the compiler to catch this, however it seems that, for some reason, it doesn't o.O

I also had to perform some code changes as apprently lua_objlen doesn't return the number of elements in a table if they aren't indexed. This was mucking up a few functions which relied on that count to work out how many parameters were called.

The 'get*FromTable' functions also needed a rejiggle as I forgot to pop any resulting 'nil' values from the stack when returning the default value. I need to change this however as the default value being returns is, in some cases, a legal value.

For the bool accesses it makes sense to return 'false' is something isn't present, however for the number accesses 0 could be a valid number. I don't want to use exceptions because a value not being there isn't an exceptional situation, for example when it comes to colour data it's perfectly reasonable to send only RGB data, so trying to read the alpha value would fail, but at the same time the default value of '0' is a valid alpha value.

I guess I could do a 'query' and then 'obtain' function pair, however I'm not overly happy with this solution.

I've got to do a time trial to my possible place of work, so I'll consider it while dodging traffic... [grin]
Sign in to follow this  

1 Comment

Recommended Comments

I've got to do a time trial to my possible place of work
I've not been keeping up with journals as much as I'd like, but I remember you writing about jobs a while back. You've got somewhere with it I take it?


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now