carray(1) is a tiny but flexible Sortix program that turns a binary file into a C file <https://sortix.org/man/man1/carray.1.html …> <https://gitlab.com/sortix/sortix/blob/master/carray/carray.c …> $ echo foo > bar $ carray bar unsigned char bar[] = { 0x66, 0x6F, 0x6F, 0x0A, };
-
-
It's a reasonable approach to not include the wrapping declaration, it also removes the need for a tool for the job (just use od + sed as you say). It's another layer of indirection though, and not super usable. carray(1) makes common cases useful without extra glue.
-
In my case, the data is output as integers from another program, and arrayify just formats it to be less offensive to include in a git repo and shit.
End of conversation
New conversation -
-
-
why not objcopy (generate the ELF directly), xxd --include and such. Why reinvent existing thing? At least grab their relevant piece of code, or stick to their syntax people already know.
-
There are very very good reasons not to do the objcopy stuff. It's an awful hack that should be forgotten except as reminder not to reinvent it.
-
Can you please explain more? I liked the idea, since the old C compiler collapsed when I gave him a very long static array. Resorted to asm .data
-
Asm .data is less awful than objcopy, but still nonportable and inherently hides the content of the data from the compiler (preventing static analysis of correctness aspects and value range based optimization).
-
Can't find the thread at the moment, but it was recently discussed that huge array blows up gcc's ast but huge string avoids it. Ugly but works.
-
Does that workaround also work for line broken strings, say 80 column implicitly appended strings? But really, a compiler benchmark is needed and then an efficient representation in the compiler.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.