ROM version build fails about elks HOT 5 CLOSED

Thanks to #27, build with option CONFIG_ROMCODE succeeded to generate setup and system object files, but now the generation of the ROM image fails at the following step:

tools/mkbootloader  -c 0xe000 64 Image 0xe000 -a boot/setup 0xe000 -s boot/system 0xe060  
  boot/setup: ffffffe0h Bytes (- a.out) @e000
  Wrong a.out table?
  boot/system: 0h Bytes (strip) @e060
Bereichsfehler in Nr. 0 (offs < basis)!
Makefile:171 : la recette pour la cible « Image » a échouée

Both setup and system object files look correct when dumping with dumpobj86.

After debugging mkbootloader, it appears that the scanf() and printf() function calls use format "%lx" (long int) to fill or display int32_t variables, causing buffer overlap if built on 64 bits system.

from elks.

I have a patch that works on my 64 bits system, where I replaced %lx by %x, but I am not sure it would not cause regression on a 32 bits system. uint32_t and such are portable with fixed size, but what about the format string of printf() and scanf () ?

from elks.

For the case of integer sizes with 32 and 64 bits systems using gcc and linux, see:

https://usrmisc.wordpress.com/2012/12/27/integer-sizes-in-c-on-32-bit-and-64-bit-linux/

So, for the program to work on 32 and 64 bit systems, all 32 bit integers should be "int" and use "%x", and all 64 bit integers should be "long long int" and use "%llx".

from elks.

Thanks Juan, so I can commit the mkbootloaderpatch that replaces %lx by %x.

from elks.

The correct way to printf() C99 integer types is covered in this Stack Overflow answer. In short, #include <inttypes.h> and use the appropriate macros from that header for the type you're working with.

Alternatively, you could cast to int for the printf() only. That's what I do sometimes. It looks better than uint32_t r = 1000; printf("reading %" PRIu32 " bytes\n", r);

from elks.