-
Notifications
You must be signed in to change notification settings - Fork 30.5k
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
path: fix win32.relative() for some Unicode paths #27662
Conversation
Perhaps for builds without intl we could utilize a polyfill, such as unorm. |
Alternatively we could ignore additional code points and only compare base symbols, but I'm not sure if that's how Windows/NTFS/etc. compares characters in paths. |
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'd rather see more work on the original PR as it's a first time contributor instead of jumping to this one. Let's hold off for the time being.
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.
This does not fix all edge cases. There could theoretically be a combination of the Russian I and the German ß. Those together could return the identical length after lowercasing the input and then still producing wrong results.
Update: I've mistaken.
@BridgeAR do you have a specific test case in mind? |
@mscdex sorry I made a mistake while looking at this earlier. It should indeed work properly in all cases (if One of these implementations could e.g. look like: "loop over the original first argument and slice out parts, lowercase them and compare them with the other side in case you find a slash." That should be almost as fast as the generic implementation. |
8ae28ff
to
2935f72
Compare
@lundibundi I guess? |
@jdalton I think your ping @nodejs/path |
Seems like it would fix a crash in my app for users with |
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.
LGTM
Please take another look. The alternative PR is long closed.
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 don't have enough background to confirm the code is 💯 but as far as I can tell it's good 👍
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@mscdex The CI is failing consistently on very specific jobs, I'm not sure if this needs action or is just flaky CI. |
@aduh95 The error in the intl-less build environment makes sense. I don't think we came to a consensus about how to handle that situation. I suggested using a pure JS polyfill for a consistent experience whether intl is available or not. @BridgeAR had a separate suggestion. Maybe someone else has additional input into this or is ok with one of these solutions? |
This issue/PR was marked as stalled, it will be automatically closed in 30 days. If it should remain open, please leave a comment explaining why it should remain open. |
@monoblaine the issue about what to do about intl-less node builds hasn't been resolved yet, so resolving merge conflicts isn't worthwhile at this point |
Oh, NOW I understand the problem here. (It took only two years) A note to my future self and other fast learners like me:
|
@mscdex is this PR still something that can/should land? Is there anything that's currently blocking? |
I'm not really the one to ask, I was just providing an alternative solution to an issue.
|
fromOrig = fromOrig.normalize('NFD'); | ||
from = fromOrig.toLowerCase(); | ||
} | ||
let toNormalized; |
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.
⚙️ (optional) Let's use false
rather than undefined
since it's boolean type:
let toNormalized; | |
let toNormalized = false; |
|
||
if (fromOrig === toOrig) | ||
return ''; | ||
|
||
from = fromOrig.toLowerCase(); | ||
to = toOrig.toLowerCase(); | ||
|
||
if (fromOrig.length !== from.length) { | ||
fromOrig = fromOrig.normalize('NFD'); |
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.
shouldn't be NFC
?
Superseded by another PR |
Fixes: #27534
This is an alternative to #27644 that avoids any performance regressions in cases where lowercased versions of paths do not differ in length to the original.
The only minor issue (in practice it may not really matter) is that return values are always returned normalized using canonical composition if the lowercased version differed in length to the original, which may be unexpected if you passed in a path that was normalized using canonical decomposition for example.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes