From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Suspicious warning in W64 build Date: Fri, 15 Sep 2017 12:12:49 +0300 Message-ID: <83a81wmijy.fsf@gnu.org> References: <1017454172.910810.1504618695244@mail.libero.it> <1146932094.13821.1504798935795@mail.libero.it> <83mv66z66p.fsf@gnu.org> <102a4c21-c275-c73e-ec53-0d85975dc968@cs.ucla.edu> <83a825znuf.fsf@gnu.org> <831snhzkgw.fsf@gnu.org> <837ex9x7vf.fsf@gnu.org> <83tw0cwcle.fsf@gnu.org> <83h8wcw3td.fsf@gnu.org> <83377vx3d0.fsf@gnu.org> <83ingnq01t.fsf@gnu.org> <83fubrpxsv.fsf@gnu.org> <83r2v9masw.fsf@gnu.org> <86a81xrndl.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1505467351 24723 195.159.176.226 (15 Sep 2017 09:22:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 15 Sep 2017 09:22:31 +0000 (UTC) Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org To: Fabrice Popineau Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 15 11:22:27 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dsmpP-0006IT-Dg for ged-emacs-devel@m.gmane.org; Fri, 15 Sep 2017 11:22:27 +0200 Original-Received: from localhost ([::1]:52198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dsmpW-0007Nb-Ao for ged-emacs-devel@m.gmane.org; Fri, 15 Sep 2017 05:22:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dsmg6-0007L2-2y for emacs-devel@gnu.org; Fri, 15 Sep 2017 05:12:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dsmg1-0008Fo-Hw for emacs-devel@gnu.org; Fri, 15 Sep 2017 05:12:50 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dsmg1-0008Fk-Ea; Fri, 15 Sep 2017 05:12:45 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2776 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dsmg0-0000Ej-Kh; Fri, 15 Sep 2017 05:12:45 -0400 In-reply-to: (message from Fabrice Popineau on Fri, 15 Sep 2017 08:55:06 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:218318 Archived-At: > From: Fabrice Popineau > Date: Fri, 15 Sep 2017 08:55:06 +0200 > Cc: Emacs developers > > # define pDWP "16llx" > ^ > > Should these be using the ptrdiff_t formatter pD from lisp.h ? > > I'd rather cast the values to "long long unsigned int" as these values are assumed to be positive, > and would be meaningless if printed in decimal. That's what I did. > There are also a bunch of warnings in dispnew.c:adjust_glyph_matrix() > because the w parameter could be NULL. Actually, some parts of the code > are protected with if (w) { ... } but much more than those ones assume that > w is not NULL. That's because they really cannot be NULL at that point. GCC 7 doesn't really understand the code, so it shouldn't emit these warnings, if it wants them to be useful. > I wonder if the whole function should not just return if w is NULL. No! That function handles 2 different cases: the window-based redisplay and the frame-based redisplay. The former is used in GUI sessions, where each window has its own glyph matrices, and manages their memory. The latter is used on TTYs, where window glyph matrices are sub-matrices of the frame glyph matrices. In the latter case, allocation and reallocation of glyphs doesn't need the pointer to the window, because it's meaningless for glyph allocation. So w is legitimately NULL in that case, but the function should still do its job. The condition matrix->pool == NULL implicitly also says that w must not be NULL, but GCC 7 doesn't understand the control flow enough to deduce that. It just saw the calls like this: adjust_glyph_matrix (NULL, f->desired_matrix, 0, 0, matrix_dim); and deduced that the first argument of adjust_glyph_matrix can be NULL (which is correct), but it didn't realize that in that case matrix->pool is never NULL. Note that the calls like the above one are made from functions that manage frame-based redisplay.