Cutest bug you have ever seen?

Quote:

---

Originally Posted by angelorohit

I was doing something like this: 1.0f / (a.OneOverMass(), b.OneOverMass());
Where, in fact, I was supposed to do this: 1.0f / (a.OneOverMass() + b.OneOverMass());

The difference was just that an addition got changed to a comma, but it made a huge difference!
Instead of getting the sum of the inverse masses of a and b, I was just getting the inverse mass of b.
This would result in a bigger impulse being applied than necessary, and create instability in the system.

---

Yet another shining example of where a TDD (test driven development) approach would have saved so much heartache.

If this equiation was a method (or function) and had a set of testcases, the problem would have been found before it was ever used as part of a larger equation.

Cutest bug? Maybe not cute, but one of the most frustrating:

Code:

---

struct foo
{
    int x;
    int y;
    int z;
    char name[100];
};

---

Then in the code, to set these structs to 0, the codebase had this in various places:

Code:

---

foo f;
memset( &f, 0, sizeof(foo) );

---

This was working for many months. Along comes a programmer who decided to use std::string instead of char arrays for the name:

Code:

---

struct foo
{
    int x;
    int y;
    int z;
    std::string name;
};

---

Now, this code still worked for Visual C++ 6.0. When it was ported to C++ Builder, the code started to crash in random places. It took me a week to figure out what was going wrong.

Hopefully I don't need to explain the problem. If anyone reading this doesn't know what's wrong, then it's time to crack open the C++ books and learn about POD and non-POD types.

Regards,

Paul McKenzie

Yes, I've come across that one. It created an intermittent bug in a totally unconnected area of the code. It took a lot of CrtCheckMemory() calls spread around the code before I tracked it down. I then made a Voodoo effigy of the coder responsible and got out the pins...

Quote:

---

Originally Posted by Paul McKenzie

Now, this code still worked for Visual C++ 6.0. When it was ported to C++ Builder, the code started to crash in random places. It took me a week to figure out what was going wrong.

Hopefully I don't need to explain the problem. If anyone reading this doesn't know what's wrong, then it's time to crack open the C++ books and learn about POD and non-POD types.

Regards,

Paul McKenzie

---

(...Paul, of course you know this...)

A perfect example of why NOT to use VC++ 6.0. It (and earlier versions) wer non-compliant in so many ways.

This is one of the reasons many of use cringe when we read a post "I am using VC++ 6.0....".

I just completed a project where I was verifying a set of tests for a major provider. Many of their questions/answers (before I corrected them) where based on the improper behaviour of VC++ 6.0 :sick:

Quote:

---

Originally Posted by TheCPUWizard

(...Paul, of course you know this...)

A perfect example of why NOT to use VC++ 6.0. It (and earlier versions) wer non-compliant in so many ways.

---

Correct. Unfortunately, we were using VC 6.0 at the time we went straight to the C++ Builder port of the code. This was around 6 years ago.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

Then in the code, to set these structs to 0, the codebase had this in various places:

Code:

---

foo f;
memset( &f, 0, sizeof(foo) );

---

---

That should never ever be done anyway. :eek:

I know that sort of thing is superseded by constructors in C++, but is there some reason it would be a bad idea in C?

Quote:

---

Originally Posted by Lindley

I know that sort of thing is superseded by constructors in C++, but is there some reason it would be a bad idea in C?

---

YES (but not nearly as bad).

The issue (in straight "C") primarily comes from a maintainability and readability issue.

If you have this type of memset scattered in your code, then finding all places in a large application that modify a specific field can be virtually impossible.

Quote:

---

Originally Posted by Zaccheus

That should never ever be done anyway. :eek:

---

Right. But I think that when programmer's see "struct" they think 'C' and start to write 'C' code when dealing with the struct.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by TheCPUWizard

YES (but not nearly as bad).

The issue (in straight "C") primarily comes from a maintainability and readability issue.

If you have this type of memset scattered in your code, then finding all places in a large application that modify a specific field can be virtually impossible.

---

But it's probably fine if contained in a struct_type_init() function, I'd say.

Quote:

---

Originally Posted by Lindley

But it's probably fine if contained in a struct_type_init() function, I'd say.

---

For straight 'C' programs, that is exactly how I do it:

(Typed in by hand for illustration only in a true 'C' program. Should NOT be used with C++!!!!)

Code:

---

typedef struct
{
    // Yada...Yada...
} SampleStruct;

void SampleStruct_Init(SampleStruct *item)
{
  memset(item, 0, sizeof(SampleStruct);
}

SampleStruct *SampleStruct_Create()
{
  SampleStruct * newStruct = (SampleStruct *) malloc(sizeof(SampleStruct));
  SampleStruct_Init(newStruct);
}

void SampleStruct_Free(SampleStruct **item)
{
  free(*item);
  item = NULL;
}

---

In fact, I have a set of utilities that automatically generate the functions for any struct. :D

Probably meant *item = NULL....but yeah, I've seen that paradigm a lot.

Quote:

---

Originally Posted by Lindley

Probably meant *item = NULL....but yeah, I've seen that paradigm a lot.

---

Yup :blush:

(However, I DID include a disclaimer :D )

Quote:

---

Originally Posted by Paul McKenzie

Cutest bug? Maybe not cute, but one of the most frustrating:

Code:

---

struct foo
{
    int x;
    int y;
    int z;
    char name[100];
};

---

Then in the code, to set these structs to 0, the codebase had this in various places:

Code:

---

foo f;
memset( &f, 0, sizeof(foo) );

---

This was working for many months. Along comes a programmer who decided to use std::string instead of char arrays for the name:

Code:

---

struct foo
{
    int x;
    int y;
    int z;
    std::string name;
};

---

Now, this code still worked for Visual C++ 6.0. When it was ported to C++ Builder, the code started to crash in random places. It took me a week to figure out what was going wrong.

Hopefully I don't need to explain the problem. If anyone reading this doesn't know what's wrong, then it's time to crack open the C++ books and learn about POD and non-POD types.

Regards,

Paul McKenzie

---

I understand what is POD and non POD types. AFAIK, POD types is like int, char and void pointer.

Non POD types are like string or object.

I wonder what worng with that.

I really is a stupid person but the most stupid person is not asking any question .

Thanks.

Quote:

---

Originally Posted by Lindley

I know that sort of thing is superseded by constructors in C++, but is there some reason it would be a bad idea in C?

---

For example, NULL pointers are not always represented by 'all bits zero'.