From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani
On 06/14/2017 03:29 AM, Philipp Stephani wrote:
>
> the commit message says "The C compiler should check the cleanup<= br> > 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<= br> > 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, would= n'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?I've considered a couple of options. I think th= e simplest and most portable one would be to compile as C++, which has dest= ructors built into the language.If that's not possible for w= hatever reason, we could introduce a macro that would create an entire wrap= per function, which could implement the cleanup as normal C function. That = would require some preprocessor metaprogramming, though, or more boilerplat= e.Alternatively we could inline most of the macros and require d= iscipline from the developers editing that code.=C2=A0
Another thing. Have you had a chance to think about related questions I
asked about recently installed portability changes? Here are the URLs:
<= /blockquote>Yes, sorry for the slow response, I'm w= orking through these now.=C2=A0
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.= Agreed. I wasn't aware of such platforms.How about using #pr= agma clang diagnostic push/pop/ignore to ignore the warnings in the specifi= c statements where they arise and we know that they are false positives? I&= #39;d much prefer that over disabling them globally in configure, because m= ost of the time the warnings are useful.=C2=A0
And I'm still puzzled as to why you're getting the Clang warnings b= ut I
am not. Are you using an older Clang? Are you passing it extra warning
options?
I'm using the Apple fork on macOS.= It's mostly identical to upstream Clang and compiles Emacs just fine, = but it is a fork and not 100% identical. I also get some of the warnings on= ly when building with -O3 (haven't checked other optimization levels).= =C2=A0