Is there a fix or a workaround for the memory leak in getpwnam?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
getpwnam()does not suffer of memory leak. Subsequent calls, indeed, will overwrite its static internal buffer.Such kind of functions are instead non-reentrant and therefore non-thread safe. Paul suggested the use of
getpwnam_r()which is the reentrant version, that is safe to be used in a multithread context.That said, memory leaks are caused by those system calls that allocate memory by means of
malloc()and leave the application the responsability tofree()the memory once the returned data has used.In these cases the RAII idiom is advisable in order to not forget to free the allocated memory — see exception safety.
std::tr1::shared_ptr<>is also a viable way: For the shared_ptr a custom deleter must be provided tofree()the raw pointer when the shared_ptr goes out of the scope.Under this perspective some dangerous functions are
scandir(),asprintf(),vasprintf()etc.