Binary includes

[Jedi/Sector One]

The C language is a great language. It features a powerful preprocessing
system and allows low-level programming so that it can be considered as an
universal language, as good for OS programming as games coding.

But one feature is missing : binary includes. When one needs to includes a
graphic object, a table, or any data one doesn't want to load from a file at
run-time, the only ialize global arrays such as :

static char table[] = { 0x25, 0x3f, 0x7f, 0x32 };

To include graphics, sounds or other larges binaries, you must use a
binary to source code converter, generating very long source codes, taking a
while to compile and lotsa disk space for nothing. Even though you can
always load all your datas from files at run-time, binary includes are, IMHO,
sometimes really useful, especially when you just have to merge tables that
would have nothing to do in an external file.

With some assemblers like DEVPAC on m68k or GEMA on PC, you got a directive
called "INCBIN <file>" that inserts directly the contents of a binary file in
the executable code. A great thing for the next release of the C standard
would be this ability of initializing an array with the content of a binary
file.

What about a syntax like :

static char table[] = {
#incbin "table.dat"
};

Even if this is fully managed by the preprocessor (so that the compilation
time won't be increased), this would save lotsa developpment time.

Another problemes with the actual ANSI C revision is that there is no way of
knowing how many items an array contains without an end mark. Just look at the
first example I gave : how is it possible to know that there are 4 items at
run-time ? The only way to do it would be to add an item like "0xff" at the
end of that array, and then to test each time an item is processed, whether it
is the end-mark constant or a classical value.

Maybe the next C standard should solve this with something like

int nbItems;
static char table[nbItems] = { 0x25, 0x3f, 0x7f, 0x32 };

nbItems has not to be const, even in C++, as we expect it to be modified to
the number of items following this initialized array.

Greetings, Frank.
--
-=)> Frank DENIS aka JEDI from SECTOR ONE / Association ONE TELEMATIQUE <(=-.
\ frank...@one.net - j...@nether.net -=- http://www.epita.edu/~denis_r /
)Serveur Minitel RTC-One : [+33 1] 48701029 - [+33 1] 48584617 V23 Videotex(
(The One BBS : [+33 1] 49887691 V34 8N1 (PC, Hp48, Mac, misc) - Paris, France)
\_-^-_. "Programming will never feature your machine, learn coding." ._-^-_/

[Dik T. Winter]

In article <43kt1g$i...@boson.epita.fr> j@the_one.epita.fr (Jedi/Sector One) writes:
> What about a syntax like :
> static char table[] = {
> #incbin "table.dat"
> };
>
> Even if this is fully managed by the preprocessor (so that the compilation
> time won't be increased), this would save lotsa developpment time.

But what would the compiler do with all that garbage once it is included?
The compiler expects tokens, so this would mean a new kind of token is
invented that stands for binary data.

>
> Another problemes with the actual ANSI C revision is that there is no way of
> knowing how many items an array contains without an end mark. Just look at the
> first example I gave : how is it possible to know that there are 4 items at
> run-time ?

sizeof(char_table) will give the expected value.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: d...@cwi.nl

[Markus Freericks]

In article <DF4Mt...@cwi.nl> d...@cwi.nl (Dik T. Winter) writes:
> > What about a syntax like :
> > static char table[] = {
> > #incbin "table.dat"
> > };
>

> But what would the compiler do with all that garbage once it is included?
> The compiler expects tokens, so this would mean a new kind of token is
> invented that stands for binary data.

#incbin could tokenize the "included" file into byte-sized objects, i.e
expand to a comma-separated list of integer literals. If #incbin is
restricted to initializing character arrays, the proposal is fine (if not
overtly necessary, as a simple script can do the same).

IMHO the _real_ problem with this proposal is the *type*: how are

static char char_table[] = {
#incbin "foo"
};

static int int_table[] = {
#incbin "foo"
};

static long long_table[] = {
#incbin "foo"
};

static float float_table[] = {
#incbin "foo"
};

to do the "right" thing? OTOH, #incbin <type>,<filename> would be simple to
implement, if machine-dependent:

static long long_table[] = {
#incbin long,"foo"
/* expands to 0x1234, 0x2364, ... , 0x2634 on a sizeof(long)=4 machine */
};

here we have all those nice issues of byte-order and
number-of-bytes-in-a-long creeping in.

-- Markus