Detecting stack or heap instances

[Anu]

Hi,

I have code like this in my legacy class library :-

class Base
{
public:
void* operator new (size_t size);
Base();

private:
unsigned int magic;
}


void* Base:perator new(size_t size)
{
void *newobj = :perator new(size);//call global operator new

//initialize the "magic"
((Base *)newobj)->magic = 0x89AE;
}

//constructor
Base::Base()
{
//if magic is "valid" then the object is allocated on heap
if (magic == 0x89AE)
{
//actions for heap object
}
else
{
//actions for stack object
}
}

All the library classes derive from Base. All this is part of a custom
caching solution. My questions are :-

1) Apart from possible uninitialized memory read in the constructor
for stack objects and the probability that the "magic" for a stack
object could be set to the valid value, is there any other problem?

2) In the operator new(), can we typecast the newly allocated chunk of
memory and start accessing the "Base" class members?

Thanks in advance

Anu.

 

[Victor Bazarov]

Hi,

I have code like this in my legacy class library :-

class Base
{
public:
void* operator new (size_t size);
Base();

private:
unsigned int magic;
}


void* Base:perator new(size_t size)
{
void *newobj = :perator new(size);//call global operator new

//initialize the "magic"
((Base *)newobj)->magic = 0x89AE;
}

//constructor
Base::Base()
{
//if magic is "valid" then the object is allocated on heap
if (magic == 0x89AE)
{
//actions for heap object
}
else
{
//actions for stack object
}
}

All the library classes derive from Base. All this is part of a custom
caching solution. My questions are :-

1) Apart from possible uninitialized memory read in the constructor
for stack objects and the probability that the "magic" for a stack
object could be set to the valid value, is there any other problem?

2) In the operator new(), can we typecast the newly allocated chunk of
memory and start accessing the "Base" class members?

The only concern I'd have would be with descendants of Base if they
have virtual functions. But thinking about it, the vtbl pointer is
usually written to the object as part of constructing, so when some
descendant's c-tor puts the proper vtbl into the object's memory,
the Base's c-tor has already done its stuff.

V

 

[James Kanze]

I have code like this in my legacy class library :-

class Base
{
public:
void* operator new (size_t size);
Base();

private:
unsigned int magic;
}

void* Base:perator new(size_t size)
{
void *newobj = :perator new(size);//call global operator new

//initialize the "magic"
((Base *)newobj)->magic = 0x89AE;
}

//constructor
Base::Base()
{
//if magic is "valid" then the object is allocated on heap
if (magic == 0x89AE)
{
//actions for heap object
}
else
{
//actions for stack object
}
}

All the library classes derive from Base. All this is part of a custom
caching solution. My questions are :-

1) Apart from possible uninitialized memory read in the constructor
for stack objects and the probability that the "magic" for a stack
object could be set to the valid value, is there any other problem?

In other words, apart the fact that it doesn't work, is there
any other problem?

2) In the operator new(), can we typecast the newly allocated chunk of
memory and start accessing the "Base" class members?

No. Formally, it's undefined behavior, period. In practice,
try it with virtual inheritance, or even ordinary multiple
inheritance, and it won't work.