C/C++ Embedded Files (2013)
4rknova.com
4rknova.com
> Explanation 1) Searches for the resource identified by h-char-sequence in implementation-defined manner.
Okay, so now I have to make assumptions that the implementation is reasonable, and won't go and "search" by asking an LLM or accidentally revealing my credit card details to a third party, right?
And even if the implementation _is_ reasonable the only way I know what "search" means in this context is by looking at an example, and the example says "it's basically a filename".
So now I think to myself: if I want to remain portable, I'll just write a python script to do a damn substitution to embed my file, which is guaranteed to work under _any_ implementation and I don't have to worry about it as soon as I have my source file.
Does anyone else feel this way or is it just me?
Sometimes it is annoying but realistically it is a good strategy.
The C++ standard says implementation defined because the weeds get very thick very quickly:
- Are paths formed with forward slash or backslash?
- Case sensitive?
- NT style drive letter or Posix style mounts?
- For relative paths, what is it relative to? When there are multiple matches, what is the algorithm to determine priority?
- What about symlinks and hard links?
- Are http and ftp URIs supported (e.g. an online IDE like godbolt). If so, which versions of those protocols? TLS 1.3+ only? Are you going to accept SHA-1?
- Should the file read be transactional?
People already complain that the C++ standard is overly complicated. So instead of adding even more complexity by redefining the OS semantics of your build platform in a language spec, they use "implementation defined" as a shorthand for "your compiler will call fopen" plus some implementation wiggle room like command line options for specifying search paths and the strategy for long paths on Windows
What if #embed steals my credit card data is a pointless strawman. If a malicious compiler dev wanted to steal your credit card data, they'd just inject the malicious code; not act like a genie, searching the C++ spec with a fine comb for a place where they could execute malicious code while still *technically* being standards conformant. You know that, I know that, we all know that. So why are we wasting words discussing it?
How can you know that your Python implementation won't send your credit card details to an LLM when it runs your script? It does not follow an ISO standard that says it can't do that. You're not making assumptions about it's behavior, are you?
GCC 15, so C23 is the default language.
And C11 was fully supported since GCC 4.9 which released in 2014.
I think in a few (3-4?) years it will be safe to use, but in any case not now.
Still, good to know that it exists.
So as long as #embed isn't supported by all the 3 major compilers, I am sticking with my current embedding setup. I guess that's what I was thinking of.
All a bit less relevant now since recent C++ versions have this built in by default. Generally something languages have been IMO too slow on (e.g. Go picked this up four or so years ago, after a bunch of less nice home-grown alternatives), it's actually just really useful to make things work in the real world, especially for languages that you can distribute as single-file binaries (which IMO should be all of them, but sadly it's not always).
https://github.com/jcalvinowens/ircam-viewer/commit/17b3533b...
it might be a bit 'arcane' way to do it idk... but to me it always seemed the logical way.. u can also define symbols etc around it and use extern in ur c/cpp program to reference those.to access the data in light of dynamic linking / alsr etc.
here is some resource on it with some examples: https://wiki.osdev.org/Linker_Scripts
u can include any file. another executable, images, etc. etc. no need for weird stuff in the c sources?
on the flipside, is there a benefit of doing it inside the source code?? (apart from not having to roll ur own linker script and learn that dragon?)
``` inline constexpr auto bootstrap = #include "bootstrap.lua" ;
// ... later
lua.script(bootstrap, "@bootstrap"); ```
The lua code ``` R"( -- your code here )"; ```
Regardless all of the methods suggested are terrible. If you don't have access to #embed, just write a trivial python script.
Just write a Python script that does the whole thing.
Is there any guarantee they won't break backwards compatibility again?
Arguably it could be a little C helper, but I wanted this particular piece of the project to be more accessible so I used a scripting language.
QNX was one. Don't know if they started to include it in newer versions than 6.5 though
Also, perl has other uses. Perl is much more competent at awk/sed/grep like tasks than python, and it can also be much faster. More people should be writing perl, imo. There's a ton of programs written in C that should just be perl.
But, I do know perl regex are very fast because they're compiled at build time. They can have high time complexity if you use lookback, but that's true of most regex implementations. Dynamic regex is definitely slower, but this is somewhat rare in most perl programs.
But, in general, perl is going to be much faster than python or bash. Bash because bash is one of the least efficient languages ever designed, forking for basic functionality, and python because python has truly awful performance characteristics.
But, I would argue, if you have a system with python, you should probably write PHP. It's faster than both and very convenient for shell scripting like things.
But if you don't have python or can't assume it, use perl. For the love of God, don't use bash.
Python has many uses, I just don't think system scripts or system utilities is one of them. That's C, perl, or bash land, and perl is clearly the frontrunner there.
That certainly depends on exactly what you're doing...
> But, I would argue, if you have a system with python, you should probably write PHP.
That's a new one, I've never heard anybody seriously advocate for PHP as a system scripting language before...
> Python has many uses, I just don't think system scripts or system utilities is one of them. That's C, perl, or bash land, and perl is clearly the frontrunner there.
Having written plenty of all of those in my life, I really disagree. Python is easier and faster to write, and for scripting that matters more than just about anything else. Performance is almost irrelevant.
The main problem with python is getting it on systems is the biggest pain in the ass imaginable. Even deploying C++ is simpler.
If you're making the script for yourself then sure, fine. As soon as you're distributing to systems you don't 100% control, drop python. It's just annoying and it's not worth it. That 150 like python script could've been a 100 line perl script, or a 150 line one if you want. And then, you can just plop the file on basically any unix-like and run it.
> The main problem with python is getting it on systems is the biggest pain in the ass imaginable.
Just avoid external dependencies and use /usr/bin/python, most scripting doesn't need any external dependencies. Or maybe I'm not understanding what you mean?
Yes, I would agree, and this has value. But if you're in the position of making the decision of what to use and you know both, then that changes things. It's the same thing with Bash. Lots of people, and sysadmins, know bash, so they write bash. But bash is still not the optimal choice for, I'd say, 90% of the stuff it's chosen for. And it's a self-eating beast. Shoving bash where it doesn't go only strengthens it's grip. You're feeding the gremlin, you know?
> Just avoid external dependencies and use /usr/bin/python
I think this is easier said than done and it's also partially cultural. I have seen many, many system scripts that assume a very recent version of python AND assume a bunch of python libraries. This is bad, and people need to stop doing this. At least have the decency to bundle the libraries or, better yet, statically link them using C or C++ or Rust or Zig or whatever. And if that seems overkill to people, I think that means they haven't considered what they're actually doing and if they even need those external libraries.
Bash has this problem, too, and much worse, because it just calls system utilities. So it assumes a very specific running environment.
Anyway, all of that being said, if you're not using any libs than maybe Python is fine, if you know the systems you're targeting will have Python. If not though, I stand by Perl. Just use 5.10 or whatever and boom, that shit will run truly anywhere.
-i output in C include file style.