On Tue, Apr 26, 2011 at 4:54 AM, Patrick Horgan <phorg...@gmail.com> wrote:
> 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.
>
> Patrick
>
>
Greetings Patrick, and everyone else -
I don't understand much of this, but it looks like you're requesting an
enhancement, so that's how I entered this, as issue 1644 :
http://code.google.com/p/lilypond/issues/detail?id=1644
Yours in peace,
Ralph
> _______________________________________________
> bug-lilypond mailing list
> bug-lilypond@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
