Cutest bug you have ever seen?

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'.

Trying to clear something like std::string with memset may or may not work, depending on how it is implemented. It also assumes that the 'cleared' state for the object is to have all of its members set to zero. This is not necessarily the case.

eg.
Both 'pdata' & 'unused' are corrupted by the memset.

Code:

---

class Data10
{
public:
        Data10() : pdata(new int [10]), unused(true)
        {               
        }

        ~Data10()
        {
                delete[] pdata;
        }

        int Get(int i)
        {
                unused = false;
                return pdata[i];
        }

        void Set(int i, int value)
        {
                unused = false;
                pdata[i] = value;
        }

        bool Unused()
        {
                return unused;
        }

private:
        int *pdata;
        bool unused;
};

int main()
{
        Data10 data;

        memset(&data, 0, sizeof(Data10)); // Error!!!
}

---

Quote:

---

Originally Posted by Peter_APIIT

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.

---

See this code and comments.

Code:

---

foo f; // f is already constructed
memset(&f, 0, sizeof(foo)); // Now you've wiped away the string data that was already constructed!!

---

What if the string sets members to certain values. By calling memset(), you have literally destroyed the string's data, and it is now in an inconsistent state.

What if the string is reference counted, and the string object has an internal reference count? Let's say the reference count set in the string is 6 (meaning there are currently 6 strings with the same data). Now you go ahead and use memset(), destroying this information. You now have a live string with a wrong reference count. Using the string causes all sorts of bad things to happen.

What if the non-POD member has an internal v-table? By memset()-ing, you've wiped out the v-table. There are so many other scenarios I could mention, and the reason why using memset() in a C++ program can get you in a lot of trouble.

Regards,

Paul McKenzie

Thanks for your all explanation.

Quote:

---

and the reason why using memset() in a C++ program can get you in a lot of trouble.

---

And would probably get you into to trouble in 'C' too for many of the same reasons.