I guess my problem is I come from an embedded programmer background - I tend to work towards the most efficient code, not necessarily the
easiest to read. That's why I suggested a char instead of an int - saves at least one byte of data. Also, creating a variable and asking printf
Except it kind of doesn't, since the argument will be promoted to an
int in accordance with the integer promotion rules anyway.
to parse your string and replace the %c with your variable will take
time to process at runtime, and will produce more bytes of code in your compiled binary. But there's nothing wrong with writing the code as I suggested, then putting in a comment explaining what it's doing :)
I don't will include a longer calling sequence and some space somewhere
for the literal, but given that you're calling printf() anyway, it won't
be appreciably longer unless you've got some form of very effective LTO
that can tell that the '%c' verb is never used and avoids whatever function printf() calls internally to handle '%c'. That's unlikely.
In my own experiment with a trivial test program, the version that uses
the variable is actually slightly smaller on x86_64, and a tiny bit larger
on i386 (16 bytes).
: grex; cat a.c
#include <stdio.h>
int
main()
{
int c = 27;
printf("%c[H\n", c);
return 0;
}
: grex; cat b.c
#include <stdio.h>
int
main()
{
printf("\033[H\n");
return 0;
}
: grex; egcc -Ofast -s -static -flto -o a a.c
: grex; egcc -Ofast -s -static -flto -o b b.c
: grex; ls -l a b
-rwxr-xr-x 1 cross staff 95048 Mar 12 23:16 a
-rwxr-xr-x 1 cross staff 95032 Mar 12 23:16 b
: grex; size a b
text data bss dec hex
82357 4808 20500 107665 1a491 a
82490 4784 19544 106818 1a142 b
: grex;
Note that the text segment for `a` is actually somewhat smaller
than for `b`, though the former has a larger data segment and BSS.
Looking at the unstripped binaries, one can see that the constant
value for the escape character is folded directly into a push-immediate instruction, whereas it's just the lea and push for the format
string in the version without the variable (this is for i386).
Results are similar for amd64:
: gaja; ls -l a b
-rwxr-xr-x 1 cross staff 104048 Mar 13 03:13 a
-rwxr-xr-x 1 cross staff 104040 Mar 13 03:13 b
: gaja; size a b
text data bss dec hex
94533 5984 20528 121045 1d8d5 a
94564 5976 19616 120156 1d55c b
: gaja;
I'm not set up at the moment to call `printf` from an embedded ARM
program, but results compiling for aarch32 are a bit more expected:
: gaja; arm-none-eabi-gcc -Wno-implicit-function-declaration -Ofast -c a.c
: gaja; arm-none-eabi-gcc -Wno-implicit-function-declaration -Ofast -c b.c
: gaja; ls -l a.o b.o
-rw-r--r-- 1 cross staff 1036 Mar 13 03:34 a.o
-rw-r--r-- 1 cross staff 1032 Mar 13 03:34 b.o
: gaja; arm-none-eabi-size a.o b.o
text data bss dec hex filename
38 0 0 38 26 a.o
32 0 0 32 20 b.o
: gaja; arm-none-eabi-strip a.o b.o
: gaja; ls -l a.o b.o
-rw-r--r-- 1 cross staff 624 Mar 13 03:34 a.o
-rw-r--r-- 1 cross staff 616 Mar 13 03:34 b.o
: gaja;
And indeed, comparing the assembler for these shows the
single additional instruction in a.o to load 27 into r1.
--- Mystic BBS v1.12 A38 2018/01/01 (Windows/32)
* Origin: Black Flag : ACiD Telnet HQ > blackflag.acid.org (21:1/112)