Re: Warning in svg_load_image

[Eli Zaretskii]

> From: Michael Welsh Duggan <mwd@md5i.com>
> Cc: Michael Welsh Duggan <mwd@md5i.com>,  luangruo@yahoo.com,
>   emacs-devel@gnu.org
> Date: Wed, 23 Feb 2022 16:58:59 -0500
> 
> > If the compiler doesn't understand that the value is being limited to
> > a maximum of 5 digits, then it shouldn't attempt to emit such
> > "helpful" warnings.
> 
> Is it being limited?  What is limiting it?  "%5.0f" will not limit it's
> size; it will only limit its minimum size, unless I am misunderstanding
> the printf specs.

That's not the limitation I had in mind, I meant the limitation of the
values printed with those formats:

>      if (buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper,
>                                foreground & 0xFFFFFF, width, height,
> -                              viewbox_width, viewbox_height,
> +                              /* Sanitize the viewBox dimensions.  */
> +                              min (max (viewbox_width, 1.), 10000.),
> +                              min (max (viewbox_height, 1.), 10000.),
>                                background & 0xFFFFFF,
>                                SSDATA (encoded_contents)))

Here, it should be clear to the compiler that:

  . the #%06X formats cannot produce more than 6 characters each
  . the %d formats cannot produce more than 12 characters each
  . the %5.0f formats cannot produce more than 5 characters each

> >> The principled way to solve this would be to call the snprintf twice,
> >> the first time with a zero-sized buffer, and then to use the return
> >> value to allocate the actual buffer.  This is a pessimisation, but I
> >> don't know if it's a bad one (it depends on how frequently this code
> >> would be called.
> >
> > This is madness.  I'd rather we used a pragma to disable that
> > particular warning around this part of the code than jump through
> > hoops because the compiler is too stupid to understand the code it
> > warns about.
> 
> Another possible option: you may be able to work around this by
> declaring buffer_size to be volatile.

That'd slow down the code in production, which is not a good idea.