[flang-commits] [clang] [libc] [clang-tools-extra] [flang] [llvm] [libcxx] [compiler-rt] [lldb] ✨ [Sema, Lex, Parse] Preprocessor embed in C and C++ (and Obj-C and Obj-C++ by-proxy) (PR #68620)

Aaron Ballman via flang-commits flang-commits at lists.llvm.org
Mon Nov 27 11:05:34 PST 2023


AaronBallman wrote:

> I'd also like to highlight the use case of diagnostic for compiler crashes. IIRC preprocessed source to attach to an issue is produced with `-frewrite-includes`, so we might want to change its behavior for `#embed`. This might be a good use case for `#embed_base64`.

I'm wary of this for privacy reasons. Including header files makes a lot of sense because there's almost no chance a reproducer will be useful without those header files. I don't think the same is true with `#embed` though it certainly is plausible. And header files can contain sensitive information, so the problem of leaking sensitive details already exists. However, with include files, you can tell at a glance if you're pulling in sensitive information because everything is textual code. I think `#embed` is a bit different in that it seems likely to contain sensitive information that would be hard to spot if it was base64 encoded; you'd need more contextual information from the code to determine what is being embedded. I think the safer approach for users would be `-E -dE` mode where the resource isn't embedded. The downside to this is: you can't immediately pass the script to Clang because the `#embed` directives likely won't find the correct file, so triage may need to reduce the test case to remove the directive. But given that we want reduced test cases anyway, maybe that's reasonable?

https://github.com/llvm/llvm-project/pull/68620


More information about the flang-commits mailing list