Sorry for the misunderstanding about the posting you answered to. I should had been more clear:   I wanted to reply with the post to critique about security risks of constexpr File IO compared to C23 #embed, not how to use #embed as a feature replacement. And compared to #embed there are only some differences in power.     As Arthur points out in turn, the central (security) difference is the use of constexpr created filepaths, which are easier to obfuscate, and not necessarily the feature of reading files per se.     Generally #embed can already read any implementation-allowed file.   So IMHO the proposal should not be treated as an absolute no-go just on the grounds of security concerns. Most of those can be mitigated by narrowing down the power.   -----Ursprüngliche Nachricht----- Von:Andrei Grosu <andrei_dg_at_[hidden]> Gesendet:Di 12.03.2024 15:28 Betreff:Re: [std-proposals] constexpr support in std::filesystem API An:Std-Proposals <std-proposals_at_[hidden]>; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; Yes, you could achive , with great pain and boilerplate code, the same result with those. Right now I am using a pre-processing stage and it does what I want, but it’s a separate stage.  The point was to have this built into the language, ‘idiomatically c++’ so to speak.  Processing files and filesystems can be useful for all kinds of scenarios, tooling for CI/CD pipelines, etc . It would be nice if the standard allowed a ‘build-in’ language feature for this, that’s the gist of it.  On Tue, Mar 12, 2024, at 16:15, Sebastian Wittmeier via Std-Proposals wrote: To be fair:   How much different is it in power from a C23 #embed?   Both feature that certain files, the ones which the implementation allows, can be fully (binarily) read at compile time.   Differences:  - the filepath can be created at runtime -> better hiding of the file read read; C23 probably supports macros for the filepath?  - the contents can be processed by constexpr functions -> probably the same can be achieved by mixing C23 with C++ constexpr  - the files could be read several times -> Denial of Service build; a long build can probably be achieved by other ways       -----Ursprüngliche Nachricht----- Von: Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet: Di 12.03.2024 15:06 Betreff: Re: [std-proposals] constexpr support in std::filesystem API An: Andrei Grosu <andrei_dg_at_[hidden]>; std-proposals_at_[hidden]; Jonathan Wakely <cxx_at_[hidden]>; CC: Tiago Freire <tmiguelf_at_[hidden]>; > That is a straw man argument. > If you had amazon.com as your home it should not have passed code review and merge request, along with whatever security audit tooling your build system should run anyways.  Its not a strawman. A standard is not just for you, it is for everyone. Including people who do open-source projects, and whose working environment isn't as closely monitored as you may think. Even in your closed environment I can think of extremely easy ways to hide malicious constexpr payload to take over your entire company and you wouldn't even notice in a PR. And that's just 5 minutes thinking about the problem, imagine what a motivated malicious actor with enough time and resources could achieve.  And why would I want to do this to begin with? -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals --  Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals