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

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

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Severity: minor

Compiling image.c on a 32-bit armv7l host gives the following warnings:

--8<---------------cut here---------------start------------->8---
image.c: In function ‘svg_load_image’:
image.c:9999:64: warning: ‘%4d’ directive output may be truncated writing between 4 and 11 bytes
                 into a region of size between 7 and 8 [-Wformat-truncation=]
 9999 |       const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}";
      |                                                                ^~~
image.c:10002:7: note: ‘snprintf’ output 37 or more bytes (assuming 38) into a destination of size 37
10002 |       snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size);
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
image.c:10134:7: warning: ‘%f’ directive output may be truncated writing between 3 and 317 bytes
                 into a region of size between 167 and 187 [-Wformat-truncation=]
10134 |       "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" "
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
image.c:10138:22: note: format string is defined here
10138 |       "viewBox=\"0 0 %f %f\">"
      |                      ^~
image.c:10134:7: note: assuming directive output of 8 bytes
10134 |       "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" "
      |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
image.c:10134:7: note: assuming directive output of 8 bytes
image.c:10134:7: note: directive argument in the range [0, 16777215]
image.c:10134:7: note: assuming directive output of 1 byte
image.c:10161:27: note: ‘snprintf’ output 320 or more bytes (assuming 331) into a destination of size 383
10161 |         || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper,
      |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10162 |                                     foreground & 0xFFFFFF, width, height,
      |                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10163 |                                     viewbox_width, viewbox_height,
      |                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10164 |                                     background & 0xFFFFFF,
      |                                     ~~~~~~~~~~~~~~~~~~~~~~
10165 |                                     SSDATA (encoded_contents)))
      |                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~
--8<---------------cut here---------------end--------------->8---

What's TRT to do?  Call snprintf twice, the first time to calculate the
required buffer size?  Calculate more precisely the resulting size of
each argument?  Inhibit the warnings?  Something else?

Some questions about the current code:

> const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}";

Why specifically '%4d' for face_font_size?

> 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?

What if xmalloc or snprintf fail?

> css = xmalloc (SBYTES (lcss) + 1);
> strncpy (css, SSDATA (lcss), SBYTES (lcss));
> *(css + SBYTES (lcss) + 1) = 0;

Can this be replaced with xlispstrdup?

Thanks,

-- 
Basil

In GNU Emacs 28.0.50 (build 1, armv7l-unknown-linux-gnueabihf, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
 of 2021-09-23 built on raspberrypi
Repository revision: 90547d370f7c75b95b1d1e64b84e624e752ea6e3
Repository branch: master
System Description: Raspbian GNU/Linux 11 (bullseye)

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/pi/.local --enable-checking=structs
 --with-x-toolkit=lucid --with-file-notification=yes --with-x'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XAW3D XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LC_ALL: en_IE.UTF-8
  value of $LANG: en_IE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils term/tmux term/xterm xterm
byte-opt gv bytecomp byte-compile cconv iso-transl tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 8 54179 7628)
 (symbols 24 6739 1)
 (strings 16 18259 2216)
 (string-bytes 1 596762)
 (vectors 8 10587)
 (vector-slots 4 130733 8726)
 (floats 8 24 229)
 (intervals 28 202 1)
 (buffers 576 10))

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

[Alan Third]

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:
> Severity: minor
> 
> Compiling image.c on a 32-bit armv7l host gives the following warnings:
> 
> --8<---------------cut here---------------start------------->8---
> image.c: In function ‘svg_load_image’:
> image.c:9999:64: warning: ‘%4d’ directive output may be truncated writing between 4 and 11 bytes
>                  into a region of size between 7 and 8 [-Wformat-truncation=]
>  9999 |       const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}";
>       |                                                                ^~~
> image.c:10002:7: note: ‘snprintf’ output 37 or more bytes (assuming 38) into a destination of size 37
> 10002 |       snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size);
>       |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> image.c:10134:7: warning: ‘%f’ directive output may be truncated writing between 3 and 317 bytes
>                  into a region of size between 167 and 187 [-Wformat-truncation=]
> 10134 |       "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" "
>       |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> image.c:10138:22: note: format string is defined here
> 10138 |       "viewBox=\"0 0 %f %f\">"
>       |                      ^~
> image.c:10134:7: note: assuming directive output of 8 bytes
> 10134 |       "<svg xmlns:xlink=\"http://www.w3.org/1999/xlink\" "
>       |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> image.c:10134:7: note: assuming directive output of 8 bytes
> image.c:10134:7: note: directive argument in the range [0, 16777215]
> image.c:10134:7: note: assuming directive output of 1 byte
> image.c:10161:27: note: ‘snprintf’ output 320 or more bytes (assuming 331) into a destination of size 383
> 10161 |         || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper,
>       |                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 10162 |                                     foreground & 0xFFFFFF, width, height,
>       |                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 10163 |                                     viewbox_width, viewbox_height,
>       |                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 10164 |                                     background & 0xFFFFFF,
>       |                                     ~~~~~~~~~~~~~~~~~~~~~~
> 10165 |                                     SSDATA (encoded_contents)))
>       |                                     ~~~~~~~~~~~~~~~~~~~~~~~~~~
> --8<---------------cut here---------------end--------------->8---
> 
> What's TRT to do?  Call snprintf twice, the first time to calculate the
> required buffer size?  Calculate more precisely the resulting size of
> each argument?  Inhibit the warnings?  Something else?

This is my code and I'm not sure, which is why there's a FIXME in
there somewhere about it.

> Some questions about the current code:
> 
> > 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.

> > 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.

> What if xmalloc or snprintf fail?

Doesn't xmalloc causes some sort of error to occur? I'm not sure. If
snprintf fails then I believe we should end up with an invalid CSS
stylesheet and librsvg will ignore it.

Perhaps there's a worse failure mode that I'm missing.

> > css = xmalloc (SBYTES (lcss) + 1);
> > strncpy (css, SSDATA (lcss), SBYTES (lcss));
> > *(css + SBYTES (lcss) + 1) = 0;
> 
> Can this be replaced with xlispstrdup?

Probably.
-- 
Alan Third

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

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

[Alan Third]

On Thu, Sep 23, 2021 at 11:38:06PM +0100, Basil L. Contovounesios wrote:
> 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...

Hmm, I guess so.

> >> > 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?

Looks that way.

I suppose in this particular case we could limit the font size to a
maximum of 9999 or something, but surely there's a better way of
calculating string sizes?

> >> 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.

None of the other uses of xmalloc in image.c check the return value
either, as far as I can see, and I certainly didn't write them all...
-- 
Alan Third

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

[Alan Third]

On Thu, Sep 23, 2021 at 11:49:37PM +0100, Alan Third wrote:
> 
> I suppose in this particular case we could limit the font size to a
> maximum of 9999 or something, but surely there's a better way of
> calculating string sizes?

Oh, can we just use Fformat and skip all of this stuff?
-- 
Alan Third

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

[Eli Zaretskii]

> Date: Thu, 23 Sep 2021 23:49:37 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 50767@debbugs.gnu.org
> 
> > >> 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.
> 
> None of the other uses of xmalloc in image.c check the return value
> either, as far as I can see, and I certainly didn't write them all...

AFAIR, there's no need to check the return value of xmalloc, because
it doesn't return if it cannot allocate memory.

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

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Thu, Sep 23, 2021 at 11:49:37PM +0100, Alan Third wrote:
> On Thu, Sep 23, 2021 at 11:38:06PM +0100, Basil L. Contovounesios wrote:
> > ...which would mean this only holds in the common case that
> > face_font_size has fewer than 5 digits, right?
> 
> Looks that way.
> 
> I suppose in this particular case we could limit the font size to a
> maximum of 9999 or something, but surely there's a better way of
> calculating string sizes?

I've implemented a pretty basic check so we shouldn't accidentally
overrun the buffer. See attached.

-- 
Alan Third

[-- Attachment #2: 0001-Fix-potential-buffer-overflow-bug-50767.patch --]
[-- Type: text/x-diff, Size: 2394 bytes --]

From 1b2ffac09c184ebc58921f2b48eacc3629596cdb Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Mon, 4 Oct 2021 22:35:41 +0100
Subject: [PATCH] Fix potential buffer overflow (bug#50767)

* src/image.c (svg_load_image): Check how many bytes were actually
written to the buffer.  Don't check xmalloc return value as xmalloc
doesn't return if it fails.
---
 src/image.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/image.c b/src/image.c
index 206c7baa2f..49b26301e8 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9996,10 +9996,16 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   if (!STRINGP (lcss))
     {
       /* Generate the CSS for the SVG image.  */
-      const char *css_spec = "svg{font-family:\"%s\";font-size:%4dpx}";
-      int css_len = strlen (css_spec) + strlen (img->face_font_family);
+      /* FIXME: The below calculations leave enough space for a font
+	 size up to 9999, if it overflows we just throw an error but
+	 should probably increase the buffer size.  */
+      const char *css_spec = "svg{font-family:\"%s\";font-size:%dpx}";
+      int css_len = strlen (css_spec) + strlen (img->face_font_family) + 1;
       css = xmalloc (css_len);
-      snprintf (css, css_len, css_spec, img->face_font_family, img->face_font_size);
+      if (css_len <= snprintf (css, css_len, css_spec,
+			       img->face_font_family, img->face_font_size))
+	goto rsvg_error;
+
       rsvg_handle_set_stylesheet (rsvg_handle, (guint8 *)css, strlen (css), NULL);
     }
   else
@@ -10157,12 +10163,11 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
 
     wrapped_contents = xmalloc (buffer_size);
 
-    if (!wrapped_contents
-        || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper,
-                                    foreground & 0xFFFFFF, width, height,
-                                    viewbox_width, viewbox_height,
-                                    background & 0xFFFFFF,
-                                    SSDATA (encoded_contents)))
+    if (buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper,
+				 foreground & 0xFFFFFF, width, height,
+				 viewbox_width, viewbox_height,
+				 background & 0xFFFFFF,
+				 SSDATA (encoded_contents)))
       goto rsvg_error;
 
     wrapped_size = strlen (wrapped_contents);
-- 
2.33.0

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

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii [2021-09-24 09:41 +0300] wrote:

>> Date: Thu, 23 Sep 2021 23:49:37 +0100
>> From: Alan Third <alan@idiocy.org>
>> Cc: 50767@debbugs.gnu.org
>> 
>> > >> 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.
>> 
>> None of the other uses of xmalloc in image.c check the return value
>> either, as far as I can see, and I certainly didn't write them all...
>
> AFAIR, there's no need to check the return value of xmalloc, because
> it doesn't return if it cannot allocate memory.

Are you thinking about xalloc?  If not, could you please point me to the
part of xmalloc that doesn't return (except for the !initialized branch
in memory_full)?  I'm afraid I couldn't spot it.

-- 
Basil

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

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Alan Third [2021-10-04 22:45 +0100] wrote:

> On Thu, Sep 23, 2021 at 11:49:37PM +0100, Alan Third wrote:
>> On Thu, Sep 23, 2021 at 11:38:06PM +0100, Basil L. Contovounesios wrote:
>> > ...which would mean this only holds in the common case that
>> > face_font_size has fewer than 5 digits, right?
>> 
>> Looks that way.
>> 
>> I suppose in this particular case we could limit the font size to a
>> maximum of 9999 or something, but surely there's a better way of
>> calculating string sizes?
>
> I've implemented a pretty basic check so we shouldn't accidentally
> overrun the buffer. See attached.

Thanks, and sorry for the late reply.  I haven't had a chance to compile
this on armv7l yet, but I should be able to later today or tomorrow.  It
continues to compile without warnings on x86_64.

-- 
Basil

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

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: Alan Third <alan@idiocy.org>,  50767@debbugs.gnu.org
> Date: Thu, 14 Oct 2021 16:42:24 +0100
> 
> > AFAIR, there's no need to check the return value of xmalloc, because
> > it doesn't return if it cannot allocate memory.
> 
> Are you thinking about xalloc?

No, I'm thinking xmalloc.

> If not, could you please point me to the part of xmalloc that
> doesn't return (except for the !initialized branch in memory_full)?
> I'm afraid I couldn't spot it.

This part:

  if (!val && size)
    memory_full (size);

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

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii [2021-10-14 12:01 -0400] wrote:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: Alan Third <alan@idiocy.org>,  50767@debbugs.gnu.org
>> Date: Thu, 14 Oct 2021 16:42:24 +0100
>> 
>> > AFAIR, there's no need to check the return value of xmalloc, because
>> > it doesn't return if it cannot allocate memory.
>> 
>> Are you thinking about xalloc?
>
> No, I'm thinking xmalloc.
>
>> If not, could you please point me to the part of xmalloc that
>> doesn't return (except for the !initialized branch in memory_full)?
>> I'm afraid I couldn't spot it.
>
> This part:
>
>   if (!val && size)
>     memory_full (size);

Sorry, I thought xsignal in memory_full would return, because I confused
it with nonlocal exits in dynamic modules which do.

Thanks,

-- 
Basil

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

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Cc: alan@idiocy.org,  50767@debbugs.gnu.org
> Date: Thu, 14 Oct 2021 17:37:23 +0100
> 
> >   if (!val && size)
> >     memory_full (size);
> 
> Sorry, I thought xsignal in memory_full would return, because I confused
> it with nonlocal exits in dynamic modules which do.

No need to be sorry.  Emacs is tricky.

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

[Alan Third]

On Thu, Oct 14, 2021 at 04:43:05PM +0100, Basil L. Contovounesios wrote:
> Alan Third [2021-10-04 22:45 +0100] wrote:
> 
> > On Thu, Sep 23, 2021 at 11:49:37PM +0100, Alan Third wrote:
> >> On Thu, Sep 23, 2021 at 11:38:06PM +0100, Basil L. Contovounesios wrote:
> >> > ...which would mean this only holds in the common case that
> >> > face_font_size has fewer than 5 digits, right?
> >> 
> >> Looks that way.
> >> 
> >> I suppose in this particular case we could limit the font size to a
> >> maximum of 9999 or something, but surely there's a better way of
> >> calculating string sizes?
> >
> > I've implemented a pretty basic check so we shouldn't accidentally
> > overrun the buffer. See attached.
> 
> Thanks, and sorry for the late reply.  I haven't had a chance to compile
> this on armv7l yet, but I should be able to later today or tomorrow.  It
> continues to compile without warnings on x86_64.

I'm not sure it'll silence the warnings, as I'm not sure what we need
to do for that, but it should at least reduce the chances of an
overflow.
-- 
Alan Third

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

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Thanks, and sorry for the late reply.  I haven't had a chance to compile
> this on armv7l yet, but I should be able to later today or tomorrow.  It
> continues to compile without warnings on x86_64.

This was three weeks ago -- the patch was applied, as far as I can tell?
Skimming this thread, it's not quite clear whether there's anything more
to do here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Alan Third]

On Fri, Nov 05, 2021 at 04:13:55AM +0100, Lars Ingebrigtsen wrote:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
> 
> > Thanks, and sorry for the late reply.  I haven't had a chance to compile
> > this on armv7l yet, but I should be able to later today or tomorrow.  It
> > continues to compile without warnings on x86_64.
> 
> This was three weeks ago -- the patch was applied, as far as I can tell?
> Skimming this thread, it's not quite clear whether there's anything more
> to do here?

I didn't expect my patch to actually silence the warnings. I've no way
to find out if it has, either.

-- 
Alan Third

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

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

>> > Thanks, and sorry for the late reply.  I haven't had a chance to compile
>> > this on armv7l yet, but I should be able to later today or tomorrow.  It
>> > continues to compile without warnings on x86_64.
>> 
>> This was three weeks ago -- the patch was applied, as far as I can tell?
>> Skimming this thread, it's not quite clear whether there's anything more
>> to do here?
>
> I didn't expect my patch to actually silence the warnings. I've no way
> to find out if it has, either.

Perhaps Basil can check?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Basil L. Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2021-11-06 19:20 +0100] wrote:

> Alan Third <alan@idiocy.org> writes:
>
>>> > Thanks, and sorry for the late reply.  I haven't had a chance to compile
>>> > this on armv7l yet, but I should be able to later today or tomorrow.  It
>>> > continues to compile without warnings on x86_64.
>>> 
>>> This was three weeks ago -- the patch was applied, as far as I can tell?
>>> Skimming this thread, it's not quite clear whether there's anything more
>>> to do here?
>>
>> I didn't expect my patch to actually silence the warnings. I've no way
>> to find out if it has, either.
>
> Perhaps Basil can check?

Sorry, I won't be able to for a while :(.  Feel free to close this bug,
and I'll chime back in when I'm at a keyboard again if necessary.

Thanks,

-- 
Basil

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

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> Sorry, I won't be able to for a while :(.  Feel free to close this bug,
> and I'll chime back in when I'm at a keyboard again if necessary.

OK; closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no