Also, using C++ with Open-AT in particular takes you out of the “mainstream” - so you become a “trail-blazer”, and your support opportunities are more limited…
I’ve used C++ in numerous embedded environments and have never suffered any problems with them. In fact the very first time I used C++ was in an embedded scenario in which I learnt how vtables work by stepping through the disassemby.
Anyway, using the malloc/free routines in “memory_stub.cpp” seems to have sorted things out 
I also have a version of my code in C (with lots of switch statements) “just in case”…
// memory_stub.cpp
#include "openat_os_interface.h"
#ifndef __REMOTETASKS__
void *malloc(size_t n)
{
return adl_memGet(n);
}
void free(void *p)
{
if (p)
adl_memRelease(p);
}
void *calloc(size_t n, size_t s)
{
void *p = malloc(n*s);
memset(p, 0, n*s);
return p;
}
#endifI wonder if daav really means Open-AT embedded applications specifically - rather than “embedded” applications in general… 
Both 
I wouldn’t recommend to a beginner in embedded world to start by C++; but it actually depends on the debugging capability of the development environment.
And for the Open AT applications case, I (and you ) know that debugging capabilities of M2M Studio are still limited. But we are working on that…
By the way, my apologizes to JasonDiplomat, since you are clearly not a beginner
Do you have a concrete bad behaviour example?
How do I turn on objdump with M2Mstudio?
If you are talking about the objdump tool, you will find it in tools\armelfgcc\4.0.1\bin sub-folder of your M2M Studio install.
Hoping the forum bug to be fixed soon, to let you add more details about the issue.
OK, thanks. Looks like the parameter passing was a red herring - second parameters were appearing as zero due to the 1st parameter to vsnprintf being an int64…