bug#43135: 28.0.50; image.c compiler warning

bug#43135: 28.0.50; image.c compiler warning

[David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

For the last week or so I'm seeing this warning when compiling master,
always using the simple command 'make' in the git repo:

  CC       image.o
image.c: In function 'svg_load_image':
image.c:9892:3: warning: implicit declaration of function 'free'
[-Wimplicit-function-declaration]
   free (wrapped_contents);
   ^
image.c:9892:3: warning: incompatible implicit declaration of built-in
function 'free'
image.c:9892:3: note: include '<stdlib.h>' or provide a declaration of
'free'

This is a 32-bit build, and Slackware 14.2's gcc is 5.5.0. The
executable runs just fine.

The warning appears after commit
8f42b94fe43911c6b0c7e519ba439d61459dc744 by Alan Third:
Set basic SVG attributes (bug#40845)

Including <stdlib.h> at the top of image.c does silence the warning.

If my toolchain is outdated please forgive and ignore the noise.

Thanks,

David.

In GNU Emacs 28.0.50 (build 36, i686-pc-linux-gnu, GTK+ Version
3.18.9, cairo version 1.14.6)
 of 2020-08-31 built on newfont
Repository revision: 58d962379546762c7eead8fc69c4c136bed8256b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
System Description: Slackware 14.2

Configured using:
 'configure
 PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XDBE XIM MODULES THREADS PDUMPER LCMS2

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.ISO8859-1
  locale-coding-system: iso-latin-1-unix

bug#43135: 28.0.50; image.c compiler warning

[Alan Third]

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

On Mon, Aug 31, 2020 at 02:52:44PM +0100, David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> For the last week or so I'm seeing this warning when compiling master,
> always using the simple command 'make' in the git repo:
> 
>   CC       image.o
> image.c: In function 'svg_load_image':
> image.c:9892:3: warning: implicit declaration of function 'free'
> [-Wimplicit-function-declaration]
>    free (wrapped_contents);
>    ^
> image.c:9892:3: warning: incompatible implicit declaration of built-in
> function 'free'
> image.c:9892:3: note: include '<stdlib.h>' or provide a declaration of
> 'free'
> 
> This is a 32-bit build, and Slackware 14.2's gcc is 5.5.0. The
> executable runs just fine.
> 
> The warning appears after commit
> 8f42b94fe43911c6b0c7e519ba439d61459dc744 by Alan Third:
> Set basic SVG attributes (bug#40845)
> 
> Including <stdlib.h> at the top of image.c does silence the warning.

Hi, can you please try the attached patch.
-- 
Alan Third

[-- Attachment #2: 0001-src-image.c-svg_load_image-Use-xmalloc-and-xfree.-bu.patch --]
[-- Type: text/plain, Size: 1525 bytes --]

From 4419564a3f9895f932c2e5dc7123eda0b64bbd0e Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Tue, 1 Sep 2020 19:53:01 +0100
Subject: [PATCH] * src/image.c (svg_load_image): Use xmalloc and xfree.
 (bug#43135)

---
 src/image.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/image.c b/src/image.c
index 35c5946c72..d8c34669cc 100644
--- a/src/image.c
+++ b/src/image.c
@@ -9830,7 +9830,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
         img->background_valid = 1;
       }
 
-    wrapped_contents = malloc (buffer_size);
+    wrapped_contents = xmalloc (buffer_size);
 
     if (!wrapped_contents
         || buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper,
@@ -9889,7 +9889,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   pixbuf = rsvg_handle_get_pixbuf (rsvg_handle);
   if (!pixbuf) goto rsvg_error;
   g_object_unref (rsvg_handle);
-  free (wrapped_contents);
+  xfree (wrapped_contents);
 
   /* Extract some meta data from the svg handle.  */
   width     = gdk_pixbuf_get_width (pixbuf);
@@ -9960,7 +9960,7 @@ svg_load_image (struct frame *f, struct image *img, char *contents,
   if (rsvg_handle)
     g_object_unref (rsvg_handle);
   if (wrapped_contents)
-    free (wrapped_contents);
+    xfree (wrapped_contents);
   /* FIXME: Use error->message so the user knows what is the actual
      problem with the image.  */
   image_error ("Error parsing SVG image `%s'", img->spec);
-- 
2.26.1

bug#43135: 28.0.50; image.c compiler warning

[David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Alan,

Yes, that works for me. Many thanks for the quick response, and please
close the bug.

David.

On Tue, 1 Sep 2020 at 19:55, Alan Third <alan@idiocy.org> wrote:
>
> On Mon, Aug 31, 2020 at 02:52:44PM +0100, David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> > For the last week or so I'm seeing this warning when compiling master,
> > always using the simple command 'make' in the git repo:
> >
> >   CC       image.o
> > image.c: In function 'svg_load_image':
> > image.c:9892:3: warning: implicit declaration of function 'free'
> > [-Wimplicit-function-declaration]
> >    free (wrapped_contents);
> >    ^
> > image.c:9892:3: warning: incompatible implicit declaration of built-in
> > function 'free'
> > image.c:9892:3: note: include '<stdlib.h>' or provide a declaration of
> > 'free'
> >
> > This is a 32-bit build, and Slackware 14.2's gcc is 5.5.0. The
> > executable runs just fine.
> >
> > The warning appears after commit
> > 8f42b94fe43911c6b0c7e519ba439d61459dc744 by Alan Third:
> > Set basic SVG attributes (bug#40845)
> >
> > Including <stdlib.h> at the top of image.c does silence the warning.
>
> Hi, can you please try the attached patch.
> --
> Alan Third

bug#43135: 28.0.50; image.c compiler warning

[Alan Third]

On Wed, Sep 02, 2020 at 07:34:39AM +0100, David Fussner via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Hi Alan,
> 
> Yes, that works for me. Many thanks for the quick response, and please
> close the bug.

Thanks, I've pushed it to master now.
-- 
Alan Third