[portej05]

Hery: Yep!

The issue becomes what happens when the compiler doesn't think that the value of 'text' is going to get changed in the function (remember, it's 'const'), so if you use const_cast weird stuff can happen when the compiler optimises your code.

[portej05]

Happy New Year all, and I've found a brief doozy for you all.

Code: [Select]

class Interface1
{
public:
virtual void Int11( ) = 0;
virtual void Int12( ) = 0;
};

class Interface2
{
public:
virtual void Int21( ) = 0;
virtual void Int22( ) = 0;
};

class MI : public Interface1, public Interface2
{
public:
virtual void Int11( ) { return; }
virtual void Int12( ) { return; }
virtual void Int21( ) { return; }
virtual void Int22( ) { return; }
};

int main( int argc, char** argv )
{
MI* i = new MI( );
Interface1* b = dynamic_cast< Interface1* >( i );
delete b;

MI* j = new MI( );
Interface2* c = dynamic_cast< Interface2* >( j );
delete c;

return 0;
}

Where and why does the above code crash (tested with MSVC2008) (Hery is away until Feb8, giving you folks a head start ).

Hint: Understanding what dynamic_cast is/does (although in this case, it could be substituted with static_cast) may help.

[Aardwolf]

I'm gonna go with "delete b;", as you've got virtual functions but no virtual destructor.

[portej05]

It's actually a bit more complex than that
Think about what dynamic_cast does, and what the values of b and c might be.

There is no issue with 'delete b', that line runs correctly (amazingly - there is a fair bit wrong with that code, but it crashes in one particular place)

[Aardwolf]

The return statement, then. Something about the local variable pointers, I think.

[Bobboau]

I'm thinking it would crash as it was shutting down, not really at the return but sometime after it, when the OS frees all the memory, it will try to free what i and j were pointing at (and leaked), part of the memory has already been freed, so it will have a 'trying to free memory you didn't allocate' error.

[portej05]

Sorry guys, not quite.
Read my previous hint
Then think about the implementation of 'delete'.

BTW, as far as I can tell (reading the standard and experimenting a little), all destructors run correctly whether delete c or delete b.

Another hint: The crash occurs at 'delete c;'

[Uchuujinsan]

Spoiler, because I cheated and used a compiler (and still didn't get it)

Spoiler:

If you make a virtual distructor for Interface2, it won't crash.

Found a little something about that matter:
http://stackoverflow.com/questions/294927/does-delete-work-with-pointers-to-base-class

Well, i == b (the address)
while j== b+2(!) (again the address), because Interface2 is placed later in the memory. That's why switching Interface1 and Interface2 in the inheritance will crash the programm at delete b.

Why exactly this all happens... don't really know, I just know I wouldn't write something like this :>
But certainly a "beautifull" bug

[portej05]

Today features a subtle bug from Wanderer:

Code: [Select]

cg->moveflag_dest = HUD_VAR(custom_gauge_moveflags[0]) + (Num_custom_gauges * sizeof(bool));

Your task:
How many bugs can you spot?

NB: HUD_VAR is a macro resolving to offsetof

[Mika]

Today features a subtle bug from Wanderer:

Code: [Select]

cg->moveflag_dest = HUD_VAR(custom_gauge_moveflags[0]) + (Num_custom_gauges * sizeof(bool));

Your task:
How many bugs can you spot?

NB: HUD_VAR is a macro resolving to offsetof

Uh-oh

Even at the risk of making myself look like a donkey, I think there are at least three.

Could you post the assigned datatypes of this snippet? What is custom_gauge_moveflags supposed to be? A boolean? I have never seen anything related to FSOpen, and can't bother to download the thing yet to check it for myself.

My guess is that this is written C++? I don't remember the boolean definition in it, but looks like if moveflag_dest is boolean (one bit for a yes/no flag?), the result of the right hand side can become something else.

Num_custom_gauges is probably integer and may become greater than 1, yet it multiplied by sizeof(bool)? Thus resulting in integer/garbage?

HUD_VAR is a macro operating to a vector (or worse, a pointer)? I don't know exactly if this is an error here, but generally macros tend to result in disasters if coder isn't exactly sure how C expands them. Especially if it has something like SOME_MACRO( int c + int b)...

ADDENDUM:
What is Num_custom_gauges * sizeof(bool) even supposed to do?

[portej05]

I'm not sure of the entire context myself - assume that custom_gauge_moveflags is a boolean array for now.
There is a bigger problem though: What is sizeof(bool)?

[sigtau]

The bit width of a certain data type, I would assume.  Booleans are raw binary values--that is to say, they are literally true or false--one or zero.

At least, I'm just taking a shot in the dark here.  That's how it works in Java, last I checked.

[portej05]

To be honest, I'm still trying to figure out if there's a problem there, but the issue I can see is that sizeof(boolean) is implementation dependent.
In addition, I believe the return value from offsetof is a size_t which causes the sizeof bool to become important.
I haven't coded up an example for this one, so would be happy to be shown either way.

[Bobboau]

sizeof(bool) == 4

yes it is that bad.

[portej05]

sizeof(bool) == 1 on my machine

[Bobboau]

rely? you've checked?what platform/build environment are you using?

[portej05]

VS2008 SP1 Win7 32bit C++

[Nuke]

id have said 2 myself, but im stupid. this whole thread is way ove rmy head, il just stick to lua and other interpreted languages