I agree. But this would also be the more expensive solution (in terms of man-hours). And also given the fact that we don't have a test framework to make sure that switching to std::string does not break anything adds a lot of risk. Whereas my little function has a defined behavior and a small risk.
As for memory leaks occurring in BOINC I'd like to quote sched/sched_version.cpp line 515: > // This is a memory leak, but that's OK Regards Christian On 03.01.2017 16:15, McLeod, John wrote: > The second would be far better. It would tend to stop memory leaks from > occurring. > > -----Original Message----- > From: Christian Beer [mailto:christian.b...@aei.mpg.de] > Sent: Tuesday, January 3, 2017 10:13 AM > To: McLeod, John <john.mcl...@sap.com>; boinc_dev@ssl.berkeley.edu > Subject: Re: [boinc_dev] [BOINC/boinc] 341001: lib: remove safe_copy(); not > used, generated compi... > > On 03.01.2017 15:29, McLeod, John wrote: >> What about the std::string function c_str? It returns a non-modifiable >> pointer to the null terminated data in the string? > This function (std::string::c_str) provides a non-modifiable pointer and > the pointer is only valid as long as the string exists. So you can't use > the pointer outside of the context of the string. So the safe_copy() > function serves two purposes. It copies a string into a new char array > to make it modifiable and usable outside of the string context. > > Another solution would be to only use strings and use c_str() locally > when it is needed and not pass around pointers to char arrays. > > Regards > Christian > _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
