https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78822
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> Dunno, you can perhaps try it (put a breakpoint somewhere before you
> construct the std::string, when you reach it, put a breakpoint on malloc and
> when you reach it, change the return value from it to NULL and see what
> happens.
So that would tell me what happens in the rare event that malloc returns NULL
because it cannot allocate the memory I need (i.e. something that xmalloc does
not do), right? What would I learn from that?
> Also, including STL headers after gcc headers is highly problematic (mainly
> because of all the poisoning in system.h).
Ouch, ok. So if I include STL first, I'm fine?
OTOH, it looks like the 'poisoning' in system.h redefines malloc:
#define malloc xmalloc
I guess that is not sufficient to make the STL use xmalloc instead of malloc,
right?
> E.g. the
> + ss << "INTENT mismatch in argument '" << s1->name << "'";
> + errmsg = ss.str();
> stuff could be easily written as:
> errmsg = concat ("INTENT mismatch in argument '", s1->name, "'",
> NULL);
> and just free it after use, but for the %i you'd have to write some helper
> routines (e.g. if you ever use at most two %i, then you could have 2 routines
> which just snprintf %i into a smallish static buffer (3 * sizeof (int)
> should be good enough) and return address of that buffer, or one routine
> that has extra argument which says which of the two buffers you want).
Well, that is essentially why I said that std::string is convenient. I really
don't wanna reimplement all of std::string and std::stringstream here, and I
don't think anyone would wanna do that.
