From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Warning in svg_load_image Date: Wed, 23 Feb 2022 19:37:24 +0200 Message-ID: <83r17tscvf.fsf@gnu.org> References: <87ilt8hcz4.fsf.ref@yahoo.com> <87ilt8hcz4.fsf@yahoo.com> <83r17wuz9s.fsf@gnu.org> <87y224e3x3.fsf@yahoo.com> <83pmnguy3w.fsf@gnu.org> <87mtihmrq0.fsf@md5i.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="873"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, emacs-devel@gnu.org To: Michael Welsh Duggan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 23 18:38:48 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nMvbD-000AeD-C1 for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Feb 2022 18:38:47 +0100 Original-Received: from localhost ([::1]:49740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMvbB-0007pA-ML for ged-emacs-devel@m.gmane-mx.org; Wed, 23 Feb 2022 12:38:45 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55374) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMvZj-00073M-Tt for emacs-devel@gnu.org; Wed, 23 Feb 2022 12:37:15 -0500 Original-Received: from [2001:470:142:3::e] (port=52306 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMvZj-0005pX-Ec; Wed, 23 Feb 2022 12:37:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GATO/H9tGo++zr4J6UvnL8fzddV6lXRTyTpgaiajTaY=; b=DOjwh9S07Tz7 KRjwDWYVSP4e3X3eaenmqpJcviV9+H31PDzvYiFdpb087myLZ6+UU42d/BWdxXMLNaRkSXEMEhCLH n9+PBRB0Hrw1bryUWaEze3Elp1TYIK3jCoJQUm99vSBa1/4kZ735JoQdfB0Hs1QnQwDfW6szfoUej ewd8YfsfD7Srn9tzdQb5xwwRTTi3daUgvNAYW8SsbzHgsJsUiJYJMKCR6CKlUJIbyweT02Zj3+wBq raFAgLLjA4M4Om4giVDg2ljN0dV9EJe7vNC5e/tpMCqep1XOeAG8D8AMWcJvUZEAaoBjAvO0mcvGz oU4AUg25rYo2tw9MVE2frg==; Original-Received: from [87.69.77.57] (port=1763 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMvZh-0007rr-TV; Wed, 23 Feb 2022 12:37:14 -0500 In-Reply-To: <87mtihmrq0.fsf@md5i.com> (message from Michael Welsh Duggan on Wed, 23 Feb 2022 12:11:24 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:286631 Archived-At: > From: Michael Welsh Duggan > Cc: Po Lu , emacs-devel@gnu.org > Date: Wed, 23 Feb 2022 12:11:24 -0500 > > Eli Zaretskii writes: > > > "xmlns:xi=\"http://www.w3.org/2001/XInclude\" " > > "style=\"color: #%06X; fill: currentColor;\" " > > "width=\"%d\" height=\"%d\" preserveAspectRatio=\"none\" " > > - "viewBox=\"0 0 %f %f\">" > > + "viewBox=\"0 0 %5.0f %5.0f\">" > > "" > > "" > > ""; > > @@ -10801,7 +10801,9 @@ svg_load_image (struct frame *f, struct image *img, char *contents, > > > > if (buffer_size <= snprintf (wrapped_contents, buffer_size, wrapper, > > foreground & 0xFFFFFF, width, height, > > - viewbox_width, viewbox_height, > > + /* Sanitize the viewBox dimensions. */ > > + min (viewbox_width, 10000.), > > + min (viewbox_height, 10000.), > > background & 0xFFFFFF, > > SSDATA (encoded_contents))) > > goto rsvg_error; > > > > So, a couple of questions and comments... > > As mentioned in other messages, % sizes affect only the minimum sizes of > results, so changing those values shouldn't help. (It's possible that > using * might, but only as a possible subversion of the heuristics that > this warning uses.) 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. > 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.