Hi
On 7/26/22 15:12, Marc-André Lureau wrote:
> On Tue, Jul 26, 2022 at 4:55 PM Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> On 7/26/22 13:25, Marc-André Lureau wrote:
>>> Hi
>>>
>>> On Tue, Jul 26, 2022 at 1:23 PM Janosch Frank <frankja@linux.ibm.com>
>> 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 <frankja@linux.ibm.com>
[...]
>> [..]
>>>> 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