Closed hikari-no-yume closed 3 years ago
Actually, if I'm interpreting the C spec correctly, it should be possible to use a string literal here! The C99 spec says (emphasis mine):
An array of character type may be initialized by a character string literal, optionally enclosed in braces. Successive characters of the character string literal (including the terminating null character if there is room or if the array is of unknown size) initialize the elements of the array.
I need to check this is true for C89 too, but it's hopeful.
Edit: Seems like this applies to C89 too.
I noticed when trying to compile some Rust-generated LLVM IR to C that non-null-terminated strings, which at the LLVM IR level are just arrays of
i8
, end up pretty gnarly compared to their null-terminated counterparts. For example:→
type definitions
```c struct l_array_37_uint8_t { uint8_t array[37]; }; #ifdef _MSC_VER #pragma pack(push, 1) #endif struct l_unnamed_7 { struct l_array_37_uint8_t field0; } __attribute__ ((packed)); #ifdef _MSC_VER #pragma pack(pop) #endif struct l_array_12_uint8_t { uint8_t array[12]; }; #ifdef _MSC_VER #pragma pack(push, 1) #endif struct l_unnamed_8 { struct l_array_12_uint8_t field0; } __attribute__ ((packed)); #ifdef _MSC_VER #pragma pack(pop) #endif ```I might try using character literals for
i8
initialisers in the printable ASCII range.{ ' U', 'n', 'r', 'e', 'c', 'o', 'g', 'n', 'i', 's', 'e', 'd', …
wouldn't be ideal of course, but it would take up no more space than the current integers, and it would be more readable.I'm not sure what's best in general for the control-character and non-ASCII ranges.