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: Thu, 24 Feb 2022 08:47:43 +0200 Message-ID: <83ilt4squo.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> <83r17tscvf.fsf@gnu.org> <8735k9meho.fsf@md5i.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7254"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mwd@md5i.com, 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 Thu Feb 24 07:51: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 1nN7yd-0001gI-Pv for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Feb 2022 07:51:48 +0100 Original-Received: from localhost ([::1]:57010 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nN7yc-0000R8-FF for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Feb 2022 01:51:46 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52816) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nN7ub-0006zZ-DF for emacs-devel@gnu.org; Thu, 24 Feb 2022 01:47:37 -0500 Original-Received: from [2001:470:142:3::e] (port=35658 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 1nN7uZ-0006hB-MJ; Thu, 24 Feb 2022 01:47:36 -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=uMKlAN8VYMZXm+rCGzRJcx3F5Ze2JFLjxDXNf1Wrm20=; b=hNeai9r13NQO pcm3tkpmY62pl46Fp83lD8Odx7SskKoYHxXikPR3h3Y7Rve9S16reLOKK5pv0f63F5OWZ+0vSiwdh w73YnJl8jgvwLq47YV+vCZFYMB6w5/HFfNLH+OzmdaVsdoxXu+uaOMLTyW0bPd9LWO9Ykt1PRiFmg ZdzZKBWOcnBSzJlLUghkc/ZRhtRcm+AjiMCiF1rpM2bji0ThUwBtbGcHusXGsw+0bljn0ZcDZQkGZ AybhTXNm4eXOeqWXq7Tw0jBFtDKlFRQqZ4I0C6YylCqBRQBOjhMPJjAG2HWz86UKP2zRpCIm8lX/e g7RUGoSXTm4umR+j0lKi8w==; Original-Received: from [87.69.77.57] (port=2536 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 1nN7uU-0005VX-LT; Thu, 24 Feb 2022 01:47:33 -0500 In-Reply-To: <8735k9meho.fsf@md5i.com> (message from Michael Welsh Duggan on Wed, 23 Feb 2022 16:58:59 -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:286648 Archived-At: > From: Michael Welsh Duggan > Cc: Michael Welsh Duggan , 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.