Hi On Tue, Jul 26, 2022 at 6:26 PM Janosch Frank wrote: > On 7/26/22 15:12, Marc-André Lureau wrote: > > On Tue, Jul 26, 2022 at 4:55 PM Janosch Frank > wrote: > > > >> On 7/26/22 13:25, Marc-André Lureau wrote: > >>> Hi > >>> > >>> On Tue, Jul 26, 2022 at 1:23 PM Janosch Frank > >> wrote: > >>>> > >>>> As sections don't have a type like the notes do we need another way to > >>>> determine their contents. The string table allows us to assign each > >>>> section an identification string which architectures can then use to > >>>> tag their sections with. > >>>> > >>>> There will be no string table if the architecture doesn't add custom > >>>> sections which are introduced in a following patch. > >>>> > >>>> Signed-off-by: Janosch Frank > [...] > >> [..] > >>>> s->length = length; > >>>> + /* First index is 0, it's the special null name */ > >>>> + s->string_table_buf = g_array_new(FALSE, TRUE, 1); > >>>> + /* > >>>> + * Allocate the null name, due to the clearing option set to true > >>>> + * it will be 0. > >>>> + */ > >>>> + g_array_set_size(s->string_table_buf, 1); > >>> > >>> I wonder if GByteArray wouldn't be more appropriate, even if it > >>> doesn't have the clearing option. If it's just for one byte, ... > >> > >> I don't really care but I need a decision on it to change it :) > >> > > > > I haven't tried, but I think it would be a better fit. > > Looking at this a second time there's an issue you should consider: > > GByteArray uses guint8 while the GArray uses gchars which are apparently > compatible with normal C chars. > > I.e. I need to cast all strings to (const guint8 *) when appending them > to the GByteArray. > Agh, boring.. well, we also have include/qemu/buffer.h that could be considered perhaps -- Marc-André Lureau