[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New warnings on emacs-26 branch with gcc 8.2.0
From: |
Andy Moreton |
Subject: |
Re: New warnings on emacs-26 branch with gcc 8.2.0 |
Date: |
Sat, 11 Aug 2018 20:04:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (windows-nt) |
On Sat 11 Aug 2018, Andy Moreton wrote:
> On Sat 11 Aug 2018, Eli Zaretskii wrote:
>
>>> From: Andy Moreton <address@hidden>
>>> Date: Sat, 11 Aug 2018 19:13:00 +0100
>>>
>>> > Does it help to take the GetProcAddress call in parentheses, like
>>> > this:
>>> >
>>> > s_pfn_Get_Module_HandleExA =
>>> > (GetModuleHandleExA_Proc) (GetProcAddress (hm_kernel32,
>>> > "GetModuleHandleExA"));
>>>
>>> Doesn't help - gcc still warns.
>>>
>>> > If this doesn't help, what about removing the cast entirely?
>>>
>>> Also still warns. This does work:
>>>
>>> s_pfn_Get_Module_HandleExA =
>>> (GetModuleHandleExA_Proc) (void (*)(void))
>>> GetProcAddress (hm_kernel32, "GetModuleHandleExA");
>>>
>>> This is sliughtly less ugly and also pacifies the warning:
>>>
>>> #define FN_PTR_CAST(fnptrtype, fnptr) \
>>> ((fnptrtype) (void (*)(void)) (fnptr))
>>>
>>> s_pfn_Get_Module_HandleExA =
>>> FN_PTR_CAST(GetModuleHandleExA_Proc,
>>> GetProcAddress (hm_kernel32, "GetModuleHandleExA"));
>>
>> I'd rather disable the warning around the code which uses these casts.
>> Or maybe we should introduce our ownj get_proc_address, which returns
>> a (void (*)(void)) pointer. But that's not for emacs-26, sorry.
For the record, with get_proc_address like this:
typedef void (*VOIDFNPTR)(void);
VOIDFNPTR
get_proc_address (HINSTANCE handle, LPCSTR fname)
{
return (VOIDFNPTR) GetProcAddress (handle, fname);
}
Then the following does not trigger the warning:
s_pfn_Get_Module_HandleExA =
(GetModuleHandleExA_Proc) get_proc_address (hm_kernel32,
"GetModuleHandleExA");
- Re: New warnings on emacs-26 branch with gcc 8.2.0, (continued)
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Eli Zaretskii, 2018/08/05
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Paul Eggert, 2018/08/05
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Eli Zaretskii, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Andy Moreton, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Eli Zaretskii, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Andy Moreton, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Eli Zaretskii, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Andy Moreton, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Eli Zaretskii, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Andy Moreton, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0,
Andy Moreton <=
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Eli Zaretskii, 2018/08/11
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Andy Moreton, 2018/08/14
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Andy Moreton, 2018/08/14
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Paul Eggert, 2018/08/14
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Eli Zaretskii, 2018/08/17
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Bruno Haible, 2018/08/18
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Paul Eggert, 2018/08/18
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Bruno Haible, 2018/08/18
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Eli Zaretskii, 2018/08/18
- Re: New warnings on emacs-26 branch with gcc 8.2.0, Paul Eggert, 2018/08/18