On 06/14/2017 03:29 AM, Philipp Stephani wrote:
>
> the commit message says "The C compiler should check the cleanup 
> attribute in the next line anyway." But that's not the case: unknown 
> attributes are silently ignored, at least in Clang. The 
> verify(__has_attribute(cleanup)) or equivalent is absolutely required 
> here. Can we revert that commit?

No, because the 'verify' breaks the build with Oracle Studio 12.5, where 
__has_attribute works only inside preprocessor conditionals. I installed 
the attached patch, which checks for __attribute__ (cleanup) in a 
different way. But while we're on the subject, wouldn't it be better if 
emacs-module.c were made to work (albeit perhaps less efficiently) even 
on compilers that do not support this nonstandard C extension?

Another thing. Have you had a chance to think about related questions I 
asked about recently installed portability changes? Here are the URLs:

http://lists.gnu.org/archive/html/emacs-devel/2017-06/msg00225.html

http://lists.gnu.org/archive/html/emacs-devel/2017-06/msg00226.html

Since then I see that you installed another patch (commit 
32d8dba625fc50ccbe28e35afcf1f0529d611e00) to pacify Clang on macOS; this 
patch unfortunately could cause trouble on non-POSIX platforms where 
rlim_t is signed. Pacifying Clang shouldn't be at the cost of 
portability or unnecessary complexity.

And I'm still puzzled as to why you're getting the Clang warnings but I 
am not. Are you using an older Clang? Are you passing it extra warning 
options?