Anyone knows what can be cause of this problem?

[Aing]

Anyone knows what can be cause of this problem?

////////////////////////////////////////////////////////////
typedef struct _date_struct {
int date,month,year;
}date_struct;

Class Date {
private :
date_struct m_data;
public :
Date& operator=(const Date& );
//.. Other stuff
};

Date::~Date()
{
FreeStruct(&m_data);
}
Date& Date:perator = (const Date& SrcDate)
{
FreeStruct(&m_Data);
///...
return * this;
}

void Date::FreeStruct(Date& lpData) //<- here is the problem.
{
memset(lpData,0,sizeof(Date));
return;
}
/////////////////////////////////////////////////////

My application crashed because lpData was set to 0x0000014 or some
address around here. (I saw from DrWatSon log) But it doesn't happen
every I run the program. Anyone can tell me where this value from ? Is
there something wrong in my code?

 

[Karl Heinz Buchegger]

Anyone knows what can be cause of this problem?

////////////////////////////////////////////////////////////
typedef struct _date_struct {
int date,month,year;
}date_struct;

Class Date {
private :
date_struct m_data;
public :
Date& operator=(const Date& );
//.. Other stuff
};

Date::~Date()
{
FreeStruct(&m_data);
}
Date& Date:perator = (const Date& SrcDate)
{
FreeStruct(&m_Data);
///...
return * this;
}

void Date::FreeStruct(Date& lpData) //<- here is the problem.
{
memset(lpData,0,sizeof(Date));
return;
}
/////////////////////////////////////////////////////

Since FreeStruct is a member function of Date, there is no need to
pass it something it can access anyway. There is also no
need to call FreeStruct from the destructor, since the object
is going to be deleted anyway. But this is not related to your problem.

My application crashed because lpData was set to 0x0000014 or some
address around here. (I saw from DrWatSon log) But it doesn't happen
every I run the program. Anyone can tell me where this value from ? Is
there something wrong in my code?

Definitly. But the problem is located somewhere else in your code.
What you see are just the symptoms. Watch out for array overflows, dangling
pointers etc.

 

[Ron Natalie]

Definitly. But the problem is located somewhere else in your code.
What you see are just the symptoms. Watch out for array overflows, dangling
pointers etc.

There seems to be some confusion.
FreeStruct takes a Date but it is passed the date_struct*. Even if he
somehow manages to bash it to compile with a cast, he's still memsetting
using the size of the containing object (Date). Depending on what "other stuff"
is in the class that he omitted form the listing, the results could be catastrophic.

 

[lilburne]

There seems to be some confusion.
FreeStruct takes a Date but it is passed the date_struct*. Even if he
somehow manages to bash it to compile with a cast, he's still memsetting
using the size of the containing object (Date). Depending on what "other stuff"
is in the class that he omitted form the listing, the results could be catastrophic.

Even if he was memsetting Date he's likely to get into problems. The
idiom of initializing by memsetting C type structures seems to a MS
thing, which doesn't work with C++ structs and classes where you are
likely to zap the vtable pointer.

 

[Karl Heinz Buchegger]

There seems to be some confusion.
FreeStruct takes a Date but it is passed the date_struct*.

I blamed this to not posting the actual source code but instead retyping
it in the newsreader.

 

[Karl Heinz Buchegger]

Even if he was memsetting Date he's likely to get into problems. The
idiom of initializing by memsetting C type structures seems to a MS
thing, which doesn't work with C++ structs and classes where you are
likely to zap the vtable pointer.

true.
But the OP used a POD struct.
memsetting to 0 should not be a problem in this case.

 

[Peter Lee]

Ron Natalie writes:

Ron> There seems to be some confusion. FreeStruct takes a Date
Ron> but it is passed the date_struct*. Even if he somehow
Ron> manages to bash it to compile with a cast, he's still
Ron> memsetting using the size of the containing object (Date).
Ron> Depending on what "other stuff" is in the class that he
Ron> omitted form the listing, the results could be catastrophic.

Even if m_data represented a Date object, he's passing a reference to
the address of that object. Seems like he would get a compile error
since the func expects (Date& lpData).

Also memset requires the address and would need to be
memset(&lpData,0,sizeof(Date));

since a reference is passed in.


Date::~Date()
{
FreeStruct(&m_data);
}
Date& Date:perator = (const Date& SrcDate)
{
FreeStruct(&m_Data);
///...
return * this;
}

void Date::FreeStruct(Date& lpData) //<- here is the problem.
{
memset(lpData,0,sizeof(Date));
return;
}

 

[Andrey Tarasevich]

Anyone knows what can be cause of this problem?

For starters, try posting real code. The code that you posted doesn't
even compile, since you are trying to pass a 'Date*' argument as 'Date&'
parameter.

 

[Andrey Tarasevich]

true.
But the OP used a POD struct.
memsetting to 0 should not be a problem in this case.
...

No, it is still a problem. You must be thinking about 'memcpy', not
about 'memset'. Strictly speaking, 'memset' cannot be used to
zero-initialize 'int' objects. And 'int' objects is exactly what the OP
is storing in his/her POD struct called 'date_struct'.

 

[Rob Williscroft]

Andrey Tarasevich wrote in

No, it is still a problem. You must be thinking about 'memcpy', not
about 'memset'. Strictly speaking, 'memset' cannot be used to
zero-initialize 'int' objects. And 'int' objects is exactly what the OP
is storing in his/her POD struct called 'date_struct'.

I was under the impression that all C++ signed types have 1 of
3 formats 2s-compliment, 1s-compliment or signed magnitude, all of
these representation's have value 0 when all bits set to 0,
so why doesn't:

int i;
memset( &i, 0, sizeof( int ) );

work ?

Rob.

 

[Andrey Tarasevich]

I was under the impression that all C++ signed types have 1 of
3 formats 2s-compliment, 1s-compliment or signed magnitude, all of
these representation's have value 0 when all bits set to 0,
so why doesn't:

int i;
memset( &i, 0, sizeof( int ) );

work ?
...

For type 'int' (and all integral types other than 'char', 'signed char'
and 'unsigned char') the total number of bits in value representation
could be smaller than the total number of bits in object representation.
Unused bits are called "padding bits". It is possible that values of
padding bits cannot be just arbitrary. Some combinations of padding bits
may produce invalid objects of type 'int' (trap representations),
leading to undefined behavior.

For example, in some implementation object representation of type 'int'
might consist of 32 bits with only 31 bits used in value representation
and 1 remaining bit used for parity check. Let's say that in that
implementation the parity bit is always set so that the total number of
1-bits in a valid object of type 'int' is always odd. In this case
zeroing an object of type 'int' with 'memset' will produce a trap
representation and cause undefined behavior.

 

[Rob Williscroft]

Andrey Tarasevich wrote in

For type 'int' (and all integral types other than 'char', 'signed
char' and 'unsigned char') the total number of bits in value
representation could be smaller than the total number of bits in
object representation. Unused bits are called "padding bits". It is
possible that values of padding bits cannot be just arbitrary. Some
combinations of padding bits may produce invalid objects of type 'int'
(trap representations), leading to undefined behavior.

For example, in some implementation object representation of type
'int' might consist of 32 bits with only 31 bits used in value
representation and 1 remaining bit used for parity check. Let's say
that in that implementation the parity bit is always set so that the
total number of 1-bits in a valid object of type 'int' is always odd.
In this case zeroing an object of type 'int' with 'memset' will
produce a trap representation and cause undefined behavior.

Thanks, I'm sure I've been told this before, I hope I remember
it this time

Rob.