Status: Accepted Owner: ---- Labels: Type-Enhancement Priority-Low
New issue 1644 by ralphbug...@gmail.com: get_working_directory () issue? http://code.google.com/p/lilypond/issues/detail?id=1644 In flower/file-name.cc there's this: string get_working_directory () { char cwd[PATH_MAX]; getcwd (cwd, PATH_MAX); return string (cwd); } Which causes this warning: file-name.cc: In function 'std::string get_working_directory()': file-name.cc:100:25: warning: ignoring return value of 'char* getcwd(char*, size_t)', declared with attribute warn_unused_result You could get rid of the warning with a minimal fix like this: string get_working_directory () { char cwd[PATH_MAX]; return getcwd (cwd, PATH_MAX); } You could do an explicit convert if the return value to string like: return string(getcwd(cwd, PATH_MAX); but std::string is happy to do the implicit conversion and it's cleaner looking. There are a couple of failure cases that can happen (there are other failure modes for getcwd, but they couldn't happen in this case since they involve not being able to allocate storage when the first argument of getcwd is NULL, or the second argument is 0 and the first non-Null, or the second is not long enough for the returned value), if the return value from getcwd is NULL then the getcwd failed and errno is set to one of: EACCESS - didn't have permission to read or search some component of the path ENOENT - the current working directory has been unlinked Both of these are rare, but could happen. If they did happen, it would be kind to tell the user why the silly thing failed, but the return value of a std::string doesn't allow for a return value that would signal an error. That means that the only thing you can do to signal an error is throw. (You could always return some well known error value in the string that would be checked, but that seems hokey.) If you call get_working_directory, and it could throw, then you would have to have a try catch block. It's called from: lily-parser-scheme.cc (ly_parse_file) which assumes it always succeeds setup_paths in lily/relocate.cc which assumes it always succeeds Both of them currently would have problems if the getcwd failed. In both cases, if you could abort with a meaningful error message about not having access to the current directory, or the current directory no longer exists, the user might be able to remedy the situation. Minimally it would be nice to get rid of the warning. _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
