bug#50767: 28.0.50; Warnings about snprintf in image.c on armv7l

[Basil L. Contovounesios]

Alan Third [2021-09-23 22:46 +0100] wrote:

> On Thu, Sep 23, 2021 at 06:04:12PM +0100, Basil L. Contovounesios via Bug
> reports for GNU Emacs, the Swiss army knife of text editors wrote:
>>
>> > const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}";
>> 
>> Why specifically '%4d' for face_font_size?
>
> I figured it unlikely that anyone would be using a font size of 10000
> pixels or larger and I wanted to set an upper limit on the string size.

AFAIK %d does not truncate numbers with more digits than the specified
width or precision...

>> > int css_len = strlen (css_spec) + strlen (img->face_font_family);
>> > css = xmalloc (css_len);
>> > snprintf (css, css_len, css_spec, img->face_font_family, 
>> > img->face_font_size);
>> > rsvg_handle_set_stylesheet (rsvg_handle, (guint8 *)css, strlen (css), 
>> > NULL);
>> 
>> Does css_len not need to include the terminating null byte?
>
> It does. If you add up the length of the spec string which includes
> the escape codes, and the length of the font name, then if the font
> size does produce it's maximum sized string of 4 characters css_len is
> exactly one byte larger than the string length.

...which would mean this only holds in the common case that
face_font_size has fewer than 5 digits, right?

>> What if xmalloc or snprintf fail?
>
> Doesn't xmalloc causes some sort of error to occur? I'm not sure.

I think it exits only while Emacs is still initialising itself before
entering the top-level command loop, and otherwise frees ballast memory
and signals a Lisp error.

At least the second snprintf in svg_load_image does check xmalloc's
return value.

-- 
Basil