From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Warnings in mingw64 builds on master Date: Mon, 17 Aug 2020 19:21:39 +0300 Message-ID: <83ft8lgs4s.fsf@gnu.org> References: <864kp47t20.fsf@gmail.com> <83a6yvkhby.fsf@gnu.org> <86v9hj7njb.fsf@gmail.com> <83tux3ive9.fsf@gnu.org> <71f2c35b-4e29-4e04-a953-62b19dc9e240@cs.ucla.edu> <83r1s7ian6.fsf@gnu.org> <2383b45e-bec6-3b24-19b2-cab0309246bf@cs.ucla.edu> <835z9iiori.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37825"; mail-complaints-to="usenet@ciao.gmane.io" Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 17 18:28:12 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k7hzX-0009k8-QI for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Aug 2020 18:28:11 +0200 Original-Received: from localhost ([::1]:48240 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7hzW-0002Yj-TN for ged-emacs-devel@m.gmane-mx.org; Mon, 17 Aug 2020 12:28:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43132) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7htV-0007nW-4u for emacs-devel@gnu.org; Mon, 17 Aug 2020 12:21:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59974) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7htT-0005SJ-Bc; Mon, 17 Aug 2020 12:21:55 -0400 Original-Received: from [176.228.60.248] (port=1144 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k7htS-0004Bg-N8; Mon, 17 Aug 2020 12:21:55 -0400 In-Reply-To: (message from Paul Eggert on Sun, 16 Aug 2020 21:21:36 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:253894 Archived-At: > Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org > From: Paul Eggert > Date: Sun, 16 Aug 2020 21:21:36 -0700 > > On 8/16/20 8:39 AM, Eli Zaretskii wrote: > > the warning it emits has nothing to > > do with correctness of the code. > > I'm not sure I follow. Although it's true that adding __attribute__ ((malloc)) > does not turn formerly-incorrect code into correct code, the same thing is true > of other function attributes like _Noreturn. But that doesn't mean we shouldn't > use function attributes. Agreed. I'm not against function attributes in general or __attribute__((malloc)) in particular. > This is not simply a matter of memcpy vs memmove. In C one must constantly worry > about aliasing. These worries are lessened with __attribute__ ((malloc)), so the > attribute is typically a win. Agreed. I was talking about the compiler option "-Wsuggest-attribute=malloc", not about using the function attributes in our code. I think including -Wsuggest-attribute=malloc in the "normal" build just risks raising the noise level for no good reason. So with that in mind, I went ahead and moved this warning into the set used when --enable-gcc-warnings.