emacs-devel
[Top][All Lists]
Advanced

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

Re: Warnings in mingw64 build on emacs-28 branch


From: Eli Zaretskii
Subject: Re: Warnings in mingw64 build on emacs-28 branch
Date: Sun, 07 Nov 2021 17:05:47 +0200

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Sun, 07 Nov 2021 14:46:51 +0000
> 
> 1) In w32.h, "prepare_standard_handles" and "reset_standard_handles"
> have "HANDLE handles[4]" argument, but the handle array has 3 elements
> in the definitions and callers.

I hope I fixed this now.

> 2) This warning has been present for a long time, and seems to be
> confusion over the flexible array handling.

I'm not sure what this is about.  We use memcpy to copy from a Lisp
vector's contents in gazillion other places, and I understand they
don't cause any warnings?  How is this place different?

> 3) This warning is new with gcc 11.
> 
> C:/emacs/git/emacs/emacs-28/src/w32heap.c: In function 'getrlimit':
> C:/emacs/git/emacs/emacs-28/src/w32heap.c:853:14: warning: 'm' may be used 
> uninitialized [-Wmaybe-uninitialized]
>   853 |         if (!VirtualQuery ((LPCVOID) &m, &m, sizeof m))
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from 
> C:/msys64/mingw64/x86_64-w64-mingw32/include/winbase.h:25,
>                  from 
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:70,
>                  from C:/emacs/git/emacs/emacs-28/src/w32common.h:24,
>                  from C:/emacs/git/emacs/emacs-28/src/w32heap.c:54:
> C:/msys64/mingw64/x86_64-w64-mingw32/include/memoryapi.h:45:28: note: by 
> argument 1 of type 'LPCVOID' {aka 'const void *'} to 'VirtualQuery' declared 
> here
>    45 |   WINBASEAPI SIZE_T WINAPI VirtualQuery (LPCVOID lpAddress, 
> PMEMORY_BASIC_INFORMATION lpBuffer, SIZE_T dwLength);
>       |                            ^~~~~~~~~~~~
> C:/emacs/git/emacs/emacs-28/src/w32heap.c:844:34: note: 'm' declared here
>   844 |         MEMORY_BASIC_INFORMATION m;
>       |                                  ^

That's a compiler bug, I think.  I see nothing wrong in the call.



reply via email to

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