-1

There are some tricks practicing C++ programmers do know like "Scope Guard" and maybe others involving references to temporaries.

I'm not a practicing C++ programmer, but I'd like to ask (of curiosity) if there is a way third party library could harm the callers' stack somehow. Maybe involving sudden destructors or some kind of other scoped lifetime magic?

rostamn739
  • 323
  • 3
  • 8
  • 1
    Sure, a third party library can easily blow away the caller's stack. It doesn't take much skill to write buggy code. The real skill is in writing bug-free code. That's the tricky part. – Sam Varshavchik Jun 10 '16 at 03:14
  • `exit(0)` tends to destroy the stack (and anything else). I don't think this is a good question, really. – MSalters Jun 10 '16 at 07:16
  • @MSalters Thank you for the feedback. Feel free to close the question. My original intent was more about the references to returned temporaries and destructors etc. – rostamn739 Jun 10 '16 at 07:27

1 Answers1

3

way third party library could harm the callers' stack

Whenever code from the third part library runs - whether an initialisation routine for a dynamically loaded library that the OS loader knows to call, or an explicit call from the client application code - it usually (in most OSes'/implementations' security model) has as much ability to screw with the stack (or any other memory) as the client application itself; for example:

void library_code()
{
    char x;
    char* p = &x;
    *(p - 2) = 23;  // undefined behaviour - may do nothing or anything,
                    // but usually overwrites stack or SIGSEGVs
    *(p + 54) = 99; // stacks might grow up or down, so may have to + or -
                    // from &x to address in-use stack memory...
}
Tony Delroy
  • 102,968
  • 15
  • 177
  • 252
  • Thank you! I guess that equally applies to the specific caller's region (or say, frame) of the call stack. Could you think of an example involving scopes/lifetime/RAII? :) – rostamn739 Jun 10 '16 at 03:28
  • 1
    The stack tends to be a continuous memory area rather than disjoint address regions; frames are just bytes therein currently used by a specific function in the current call stack, wherein there might be a few saved CPU/GPU registers to be restored after the call, as well as a return address, followed by the function parameters and local variables that the compiler's opted to put on the stack. Re scopes/lifetime/RAII - any stack-hosted object's destructor can do the same kind of stack trashing via the `this` pointer. – Tony Delroy Jun 10 '16 at 03:38