emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suspicious warning in W64 build


From: Eli Zaretskii
Subject: Re: Suspicious warning in W64 build
Date: Fri, 15 Sep 2017 12:12:49 +0300

> From: Fabrice Popineau <address@hidden>
> Date: Fri, 15 Sep 2017 08:55:06 +0200
> Cc: Emacs developers <address@hidden>
> 
>  # 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]