Wrong pointer comparison in w32fns.c

Wrong pointer comparison in w32fns.c

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Presumably, this is a bug in rarely used code (affecting NT 4 systems):

  CC       w32fns.o
w32fns.c: In function 'setup_w32_kbdhook':
w32fns.c:2738:24: warning: the comparison will always evaluate as 'true'
for the address of 'newTitle' will never be NULL [-Waddress]
 2738 |           if (newTitle != NULL)
      |                        ^~
w32fns.c:2733:19: note: 'newTitle' declared here
 2733 |           wchar_t newTitle[64];
      |                   ^~~~~~~~

requiring something like this:

diff --git i/src/w32fns.c w/src/w32fns.c
index 5f652ae9e4..46c73f762a 100644
--- i/src/w32fns.c
+++ w/src/w32fns.c
@@ -2734,8 +2734,7 @@ setup_w32_kbdhook (void)
   int i;

   CoCreateGuid (&guid);
-  StringFromGUID2 (&guid, newTitle, 64);
-  if (newTitle != NULL)
+  if (StringFromGUID2 (&guid, newTitle, 64) && newTitle[0])
     {
       GetConsoleTitleW (oldTitle, 1024);
       SetConsoleTitleW (newTitle);

[-- Attachment #2: Type: text/html, Size: 1154 bytes --]

Re: Wrong pointer comparison in w32fns.c

[Po Lu]

Juanma Barranquero <lekktu@gmail.com> writes:

> Presumably, this is a bug in rarely used code (affecting NT 4 systems):
>
>   CC       w32fns.o
> w32fns.c: In function 'setup_w32_kbdhook':
> w32fns.c:2738:24: warning: the comparison will always evaluate as 'true' for the address of 'newTitle' will never be NULL [-Waddress]
>  2738 |           if (newTitle != NULL)
>       |                        ^~
> w32fns.c:2733:19: note: 'newTitle' declared here
>  2733 |           wchar_t newTitle[64];
>       |                   ^~~~~~~~
>
> requiring something like this:
>
> diff --git i/src/w32fns.c w/src/w32fns.c
> index 5f652ae9e4..46c73f762a 100644
> --- i/src/w32fns.c
> +++ w/src/w32fns.c
> @@ -2734,8 +2734,7 @@ setup_w32_kbdhook (void)
>    int i;
>  
>    CoCreateGuid (&guid);
> -  StringFromGUID2 (&guid, newTitle, 64);
> -  if (newTitle != NULL)
> +  if (StringFromGUID2 (&guid, newTitle, 64) && newTitle[0])

Does this function support Windows 9x?
http://winapi.freetechsecrets.com/ole/OLEStringFromGUID2.htm says
nothing about that.

Re: Wrong pointer comparison in w32fns.c

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> Date: Sun, 30 Oct 2022 08:57:17 +0800
> 
> > +  if (StringFromGUID2 (&guid, newTitle, 64) && newTitle[0])
> 
> Does this function support Windows 9x?
> http://winapi.freetechsecrets.com/ole/OLEStringFromGUID2.htm says
> nothing about that.

That function is supported on Windows 9X, judging by the fact that its
prototype in the mingw.org's w32api headers is not guarded by any
value of _WIN32_WINNT.

Re: Wrong pointer comparison in w32fns.c

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 30 Oct 2022 00:36:20 +0200
> 
> Presumably, this is a bug in rarely used code (affecting NT 4 systems):
> 
>   CC       w32fns.o
> w32fns.c: In function 'setup_w32_kbdhook':
> w32fns.c:2738:24: warning: the comparison will always evaluate as 'true' for the address of 'newTitle' will
> never be NULL [-Waddress]
>  2738 |           if (newTitle != NULL)
>       |                        ^~
> w32fns.c:2733:19: note: 'newTitle' declared here
>  2733 |           wchar_t newTitle[64];
>       |                   ^~~~~~~~
> 

Isn't it simply a typo?  The intent was to test oldTitle, which is
dynamically allocated by malloc.  Right?

Re: Wrong pointer comparison in w32fns.c

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 128 bytes --]

Ah, possibly.

The output of StringFromGUD2 is then not checked, though perhaps it's
assumed it will always fit in 64 wchar_t..

[-- Attachment #2: Type: text/html, Size: 159 bytes --]

Re: Wrong pointer comparison in w32fns.c

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 30 Oct 2022 13:13:06 +0100
> Cc: emacs-devel@gnu.org
> 
> Ah, possibly.
> 
> The output of StringFromGUD2 is then not checked, though perhaps it's assumed it will always fit in 64
> wchar_t..

It should be, since the GUID is a 128-bit number.

Anyway, I've made a change that should take care of both of these
issues.

Thanks.