Anyone knows what can be cause of this problem?

Discussion in 'C++' started by Aing, Feb 19, 2004.

  1. Aing

    Aing Guest

    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::eek: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?
    Aing, Feb 19, 2004
    #1
    1. Advertising

  2. Aing wrote:
    >
    > 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::eek: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.

    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, Feb 19, 2004
    #2
    1. Advertising

  3. Aing

    Ron Natalie Guest

    "Karl Heinz Buchegger" <> wrote in message news:...
    >> > 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.


    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.
    Ron Natalie, Feb 19, 2004
    #3
  4. Aing

    lilburne Guest

    Ron Natalie wrote:
    > "Karl Heinz Buchegger" <> wrote in message news:...
    >
    >>>>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.

    >
    >
    > 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.
    lilburne, Feb 19, 2004
    #4
  5. Ron Natalie wrote:
    >
    > "Karl Heinz Buchegger" <> wrote in message news:...
    > >> > 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.

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

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



    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, Feb 19, 2004
    #5
  6. lilburne wrote:
    >
    > Ron Natalie wrote:
    > > "Karl Heinz Buchegger" <> wrote in message news:...
    > >
    > >>>>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.

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


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


    --
    Karl Heinz Buchegger
    Karl Heinz Buchegger, Feb 19, 2004
    #6
  7. Aing

    Peter Lee Guest

    >>>> 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::eek:perator = (const Date& SrcDate)
    {
    FreeStruct(&m_Data);
    ///...
    return * this;
    }

    void Date::FreeStruct(Date& lpData) //<- here is the problem.
    {
    memset(lpData,0,sizeof(Date));
    return;
    }
    Peter Lee, Feb 19, 2004
    #7
  8. Aing wrote:
    > 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.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Feb 20, 2004
    #8
  9. Karl Heinz Buchegger wrote:
    >> ...
    >> 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.
    > ...


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

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Feb 20, 2004
    #9
  10. Andrey Tarasevich wrote in news::

    > Karl Heinz Buchegger wrote:
    >>> ...
    >>> 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.
    >> ...

    >
    > 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.
    --
    http://www.victim-prime.dsl.pipex.com/
    Rob Williscroft, Feb 20, 2004
    #10
  11. Rob Williscroft wrote:
    >> ...
    >> 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 ?
    > ...


    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.

    --
    Best regards,
    Andrey Tarasevich
    Andrey Tarasevich, Feb 20, 2004
    #11
  12. Andrey Tarasevich wrote in news::

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


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

    Rob.
    --
    http://www.victim-prime.dsl.pipex.com/
    Rob Williscroft, Feb 20, 2004
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ersin Gençtürk
    Replies:
    4
    Views:
    564
    Ersin Gençtürk
    Jun 30, 2003
  2. sincethe2003
    Replies:
    6
    Views:
    2,452
    sincethe2003
    Jul 19, 2004
  3. Karl Seguin
    Replies:
    3
    Views:
    537
    bruce barker
    Oct 25, 2004
  4. Alan Ho
    Replies:
    15
    Views:
    4,046
  5. Replies:
    12
    Views:
    498
Loading...

Share This Page