-
Notifications
You must be signed in to change notification settings - Fork 265
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
QPDF incompatible with LLVM 18's LibC++ due to removal of non-standard char_traits<unsigned char> #1024
Comments
My understanding is that either std::string (e.g. std::basic_string<char>) or std::vector<unsigned char> would be equally valid (based on https://stackoverflow.com/a/15172304 anyway). Though this code is probably just as easy to express as a vector than as a string, and that allows keeping the Thanks. |
Pull Request: #1025 |
@zclifford Thanks for coming back and closing the ticket. I wasn't keeping it open just because it was a power of 2. :-) |
It definitely felt like I got a lucky number there 😊. I assume that means that C++ has blessed me and I didn't mess up the pointer arithmetic in my pull request. |
This was regressed in 11.9.0 by QPDF_Name::analyzeJSONEncoding in 4319874 No biggie, I expected this could happen (and now I can catch it real fast since my workplace switched to a compiler config that hits it :).
I can send a follow up commit to re-fix it tomorrow, haven't looked too deeply yet (I realized there was a QPDF update at like 17:00). But gah this issue is still annoying, clang is too picky :D I'm not aware of a replacement for basic_string_view here (except maybe C++20 ranges, which aren't in C++17), so I guess the easiest fix is moving the cast down to the for loop and working with a normal |
string_view<unsigned char> leads to char_traits<unsigned char> which is not standard C++ (background in qpdf#1024). This triggers compilation failures with certain C++20 compiler configurations. Here the goal was to iterate over a string without copying it, but treating the chars as unsigned. It seems like moving the char -> unsigned char cast to the for loop's range declaration should work.
…d in qpdf#1024). This triggers compilation failures with certain C++20 compiler configurations. To avoid this I moved the cast to the loop's body.
Hello,
Once again my company is trying to compile with bleeding edge C++. And tasked me with resolving a QPDF compilation error that occurs with LLVM 18's LibC++ -- I don't think this has been released yet, much less to any distros, so standard tooling won't yet reproduce the issue.
This time it's char_traits. Previously LibC++ came with a non-standard implementation of char_traits which would happily work with types not listed in the standard. (Further links: Announcement, Bug, Commit)
(n.b. char8_t was added to the spec in C++20, and isn't part of C++17)
It seems like QPDF relies on this here:
Here
unsigned char
is none of the above types, and so fails to compile.I'll have to take a closer look at how this is used to think of how to work around that, but I assume you'd be OK with me sending another PR once I understand it a bit better, to keep things standards compatible?
Probably it could either be a
std::string
or anstd::vector<unsigned char>
The text was updated successfully, but these errors were encountered: