From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: nsterm.m warnings Date: Thu, 05 Jan 2012 08:31:05 +0100 Message-ID: <4F0551B9.5080305@swipnet.se> References: <327FD938-2CED-4F59-8836-065EA3B97AE7@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1325748681 6615 80.91.229.12 (5 Jan 2012 07:31:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 Jan 2012 07:31:21 +0000 (UTC) Cc: Emacs developers To: Carsten Mattner Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 05 08:31:16 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rihn8-0000KF-8v for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 08:31:14 +0100 Original-Received: from localhost ([::1]:35813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rihn7-0002NN-Q7 for ged-emacs-devel@m.gmane.org; Thu, 05 Jan 2012 02:31:13 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:38665) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rihn4-0002Mk-Rj for emacs-devel@gnu.org; Thu, 05 Jan 2012 02:31:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rihn3-0004hr-Np for emacs-devel@gnu.org; Thu, 05 Jan 2012 02:31:10 -0500 Original-Received: from mailout.melmac.se ([62.20.26.67]:37364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rihn3-0004hh-Gg for emacs-devel@gnu.org; Thu, 05 Jan 2012 02:31:09 -0500 Original-Received: from mail01.melmac.se (mail01.melmac.se [62.20.26.80]) by mailout.melmac.se (Postfix) with ESMTP id 7917B9F9C for ; Thu, 5 Jan 2012 08:31:07 +0100 (CET) Original-Received: (qmail 14088 invoked by uid 89); 5 Jan 2012 07:30:04 -0000 Original-Received: from h-46-59-42-18.na.cust.bahnhof.se (HELO coolsville.localdomain) (boel.djarv@bdtv.se@46.59.42.18) by mail01.melmac.se with ESMTPA; 5 Jan 2012 07:30:04 -0000 Original-Received: from [10.225.16.26] (unknown [193.45.43.33]) by coolsville.localdomain (Postfix) with ESMTPSA id A573B7FA058; Thu, 5 Jan 2012 08:31:06 +0100 (CET) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 62.20.26.67 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:147324 Archived-At: Carsten Mattner skrev 2012-01-05 00:49: > On Wed, Jan 4, 2012 at 8:57 PM, Jan Dj=E4rv wrote: >> >> 4 jan 2012 kl. 18:53 skrev Carsten Mattner: >> >>> I think at least one of the following or ideally both should be fixed= . >>> >>> nsterm.m: In function =91-[EmacsView conversationIdentifier]=92: >>> nsterm.m:5053: warning: conflicting types for =91-(long >>> int)conversationIdentifier=92 >>> /System/Library/Frameworks/AppKit.framework/Headers/NSInputManager.h:= 25: >>> warning: previous declaration of =91-(NSInteger)conversationIdentifie= r=92 >> >> What do you mean by "both"? This is only one warning. > > It's the same cause, but two warning messages. > You could logically group them to one, yes. I see it as one warning message. There are two "warning:" in there, but=20 they only make sense together. > >> It has no practical importance, and only occurs if you build a 32-bit >> executable, which is rare on OSX. > > If it's safe to ignore in a 32-bit build, ok. > Strictly speaking the code is incorrect, isn't it? The code relies on the fact that the compiler can convert a long to an=20 int on a 32-bit build. In principle such a conversion can truncate the=20 value. But in this case it does not matter, as long as the value is=20 unique within the application (Emacs). As the build is 32-bit, the=20 pointer converted to long is 32-bit to start with. That long is then=20 converted to an int, so there is no truncation. But it is bad style to change interfaces like this, I'll fix it shortly.=20 I guess it was long at some point in time, and then got changed to=20 NSInteger. Jan D.