🚀 go-pugleaf

In article <DF4Mt0.Cvw@cwi.nl> dik@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