-
-
Notifications
You must be signed in to change notification settings - Fork 8.3k
mingw: Add implementation of realpath() #554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Still CRLF. |
The mingw port used _fullpath() until now, but the behaviour is not exactly the same as realpath()'s on unix; major difference being that it doesn't return an error for non-existing files, which would bypass main's error checking and bail out without any error message. Also realpath() will return forward slashes only since main() relies on that.
again, apologies |
If you're interested, I have a little tool I wrote called CountLineEndings: It also counts lines with trailing spaces. On Sat, May 3, 2014 at 8:42 AM, stinos notifications@github.com wrote:
Dave Hylands |
LOL - Damn copy/paste. There is another utility I wrote called 2dos and 2unix in a parallel directory. I'll fix the comment. |
} else if (access(path, R_OK) == 0) { | ||
ret = resolved_path; | ||
if (ret == NULL) | ||
ret = malloc(_MAX_PATH); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO wouldn't
if (resolved_path != NULL) {
ret = resolved_path;
} else {
ret = malloc(_MAX_PATH);
}
be slightly cleaner here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If is always preferred to if/else, unless if gets less efficient than if/else.
The cleanest here IMHO would be avoiding introducing "ret" var and just using resolved_path which is there anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, I just wondered if having to do one less assignment in the resolved_path == NULL
case might be more efficient. But optimising low-level C code isn't my area of expertise ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did that first but that ended up with multiple returns statements - I am fine with that, but I had the idea most uPy sources didn't use it. Checked again though, and I was wrong, it's used in multiple places..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lurch : jumps are the most inefficient on average, and to be avoided. Simple assignments is 1 cycle almost on each CPU.
@stinos: Sure, returns, break, continue are used well and make it much easier to reason about control flow than ladders and ladders of if/else's or same ladders of conditional expressions in if/while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't realise an if/else jump was more expensive than just an if jump.
The mingw port used _fullpath() until now, but the behaviour is not exactly
the same as realpath()'s on unix; major difference being that it doesn't
return an error for non-existing files, which would bypass main's error
checking and bail out without any error message when the input file does not exist.
Also realpath() will return forward slashes only since main() relies on that.