Issue 1644 in lilypond: get_working_directory () issue?

[lilypond]

Status: Accepted
Owner: ----
Labels: Type-Enhancement Priority-Low

New issue 1644 by address@hidden: 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.