I don't care about the function. I'll just put it back in when I need it again. What I'm more offended by is the reason that is stated in the commit message. In my opinion that is not a valid reason to remove contributed code without discussion or the chance for the contributor to explain purpose or rectify errors.
- This function represents a nice way to convert std::string to char* and may become handy in the future. I put it in BOINC because it is not project-specific and may be something projects find helpful to be in the BOINC library. - Indicating implementation details in function names is not useful in this context in my opinion. From the name alone I wouldn't think that I need to free the memory myself. Such kind of post conditions are usually expressed in a descriptive comment above the function. Usually in a format that can be understood by a documentation tool like doxygen where the post condition would then be part of the developer documentation (the place where I would look for such post conditions). - With a proper post condition that states "You are the owner of the allocated memory of this function, clean this up after you used it" it should be clear who the owner is. Regards Christian On 19.12.2016 22:02, David Anderson wrote: > I'll put it back if you feel that strongly. > I removed it because: > - it's not used anywhere (if needed for project-specific code, can > define it there) > - the name should be something like safe_copy_alloc() to indicate that > it allocates memory > - I try to avoid memory allocation in BOINC because pointer ownership > is gnarly. > . > - David > > On 12/19/2016 5:18 AM, Christian Beer wrote: >> Hi, >> >> am I the only one who has a problem with this commit? >> >> The BOINC Governance document states that actions of Committers are >> reviewed after they committed something. Here we are. I want to complain >> about this commit by a Committer of the BOJNC project. >> >> I added this function for a reason and yes it was intended to be used in >> the server which means Linux only. So if it produces compile errors on >> Windows we do have better options than removing it from the library. The >> fact that it is currently not used in the BOINC code should not be the >> sole reason to throw it away. hat if a project uses this function in >> project specific daemons? >> >> Regards >> Christian >> >> On 19.12.2016 10:17, GitHub wrote: >>> Branch: refs/heads/master >>> Home: https://github.com/BOINC/boinc >>> Commit: 3410015b00f13f53e8284e668b503b31c20814e4 >>> >>> https://github.com/BOINC/boinc/commit/3410015b00f13f53e8284e668b503b31c20814e4 >>> Author: David Anderson <da...@ssl.berkeley.edu> >>> Date: 2016-12-19 (Mon, 19 Dec 2016) >>> >>> Changed paths: >>> M lib/str_util.cpp >>> M lib/str_util.h >>> >>> Log Message: >>> ----------- >>> lib: remove safe_copy(); not used, generated compile warnings on Win >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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. _______________________________________________ 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.