[Ace-users] [ace-bugs] Missing copy constructor/assignment operator for ACE_Log_Record

[Jan Kalin]

    ACE VERSION: 5.5.7

    HOST MACHINE and OPERATING SYSTEM:
	Intel Core2, Windows XP SP2, Winsock2

    TARGET MACHINE and OPERATING SYSTEM, if different from HOST:
    COMPILER NAME AND VERSION (AND PATCHLEVEL):
	Borland C++ Builder 6, Update pack 4

    THE $ACE_ROOT/ace/config.h FILE [if you use a link to a platform-
    specific file, simply state which one]:
	#define __ACE_INLINE__ 1
	#define _USE_OLD_RW_STL
	#define _WINSOCKAPI_
	#include "ace/config-win32.h"

    THE $ACE_ROOT/include/makeinclude/platform_macros.GNU FILE [if you
    use a link to a platform-specific file, simply state which one
    (unless this isn't used in this case, e.g., with Microsoft Visual
    C++)]: 

    CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
    (used by MPC when you generate your own makefiles):

    AREA/CLASS/EXAMPLE AFFECTED:
	Using ACE_Log_Record

    DOES THE PROBLEM AFFECT:
        COMPILATION? NO
        LINKING? NO
            On Unix systems, did you run make realclean first?
        EXECUTION? YES
        OTHER (please specify)?

    SYNOPSIS:
	ACE_Log_Record has neiter copy constructor nor assignment
	operator.

    DESCRIPTION:
	I just got bitten by this when I tried making a copy of
	ACE_Log_Record. I started getting weird access violations where
	previously the program worked well. Going through the code it
	became obvious that, of course the access violations would
	result from this, as the compiler generates a default copy
	constructor so you have two objects whose msg_data_ pointers
	point to the same piece of memory. On destruction of one object,
	the other's pointer is invalid.

    REPEAT BY:
	ACE_Log_Record a;
	{
		ACE_Log_Record b(a);  // Either this
		ACE_Log_Record c = a; // Or this
	}
	std::cout << a.msg_data(); // DIES

    SAMPLE FIX/WORKAROUND:
	I would suggest declaring hidden copy constructor and assignment
	operator for ACE_Log_Record. I realise that copies of
	ACE_Log_Record are rarely, if ever, needed, but it seems
	sanitary to prevent this kind of problem.

Best regards,
Jan Kalin