Skip to content
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

Salvage #13772 #13935

Conversation

Swiftb0y
Copy link
Member

Simplified alternative of #13772 which implements the original scope I proposed.

CC @christophehenry @JoergAtGithub

Allow to convert from UTF-8 to whatever encoding the device supports
@Swiftb0y Swiftb0y force-pushed the review/christophehenry/gh13772-charset-encoding-salvage branch 4 times, most recently from f4219e9 to bd5996c Compare November 25, 2024 14:25
@Swiftb0y Swiftb0y force-pushed the review/christophehenry/gh13772-charset-encoding-salvage branch from bd5996c to d131d1c Compare November 25, 2024 22:04
Copy link
Member

@acolombier acolombier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

src/test/controllerscriptenginelegacy_test.cpp Outdated Show resolved Hide resolved
Returning part of a usable result instead of nullbytes since
those likely terminate the string early or even corrupt the
underlying binary message format the buffer is embedded in.
@Swiftb0y Swiftb0y requested a review from acolombier November 27, 2024 19:39
@JoergAtGithub JoergAtGithub dismissed their stale review November 27, 2024 21:50

Blocking issue resolved

const char* encoderName = encoderNameArray.constData();
#endif
QStringEncoder fromUtf16 = QStringEncoder(encoderName);
if (!fromUtf16.isValid()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why you removed the flags here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see the commit message, writing the replacement char is better than replacing with null bytes IMO.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may be a problem. During the tests I noticed that replacement char varies between Ubuntu and Fedora (maybe between Qt versions). Replace invalid chars with \0x00 is the most predictable option.

Copy link
Member Author

@Swiftb0y Swiftb0y Nov 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure? I think it depends on the encoding. The Qt docs say they use QChar::ReplacementCharacter or a question mark.

Copy link
Contributor

@christophehenry christophehenry Nov 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I noticed here. The relevant commit is probably this one. Although I tested your branch and the tests pass here too so I'm not sure anymore.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll try to reproduce later this week if I have time but I don't think this should be a blocker. We'll have time to change it later or introduce a new API if this proves unstable.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about QStringEncoder::Flag::WriteBom ?
Should we set it or not? I think it's easier to remove a unwanted BOM in JavaScript, than to add the correct BOM in JavaScript.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@christophehenry The flags here are the last open point, did you find to check this out?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh sorry I didn't know you were waiting for me. I couldn't reproduce this. Feel free to merge as is.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, than lets merge this!

@christophehenry
Copy link
Contributor

Since this PR implements the consensus, can I close #13772?

@Swiftb0y
Copy link
Member Author

Swiftb0y commented Dec 4, 2024

@JoergAtGithub Anything left to do here? Pre-commit failure is unrelated. The commit history is garbage so I'd like to squash everything into a single commit.

@Swiftb0y Swiftb0y force-pushed the review/christophehenry/gh13772-charset-encoding-salvage branch from c992b43 to 3101eff Compare December 4, 2024 18:37
@JoergAtGithub JoergAtGithub merged commit fc59bff into mixxxdj:main Dec 17, 2024
10 of 13 checks passed
@Swiftb0y Swiftb0y deleted the review/christophehenry/gh13772-charset-encoding-salvage branch December 17, 2024 21:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants