nsterm.m warnings

nsterm.m warnings

[Carsten Mattner]

I think at least one of the following or ideally both should be fixed.

nsterm.m: In function ‘-[EmacsView conversationIdentifier]’:
nsterm.m:5053: warning: conflicting types for ‘-(long
int)conversationIdentifier’
/System/Library/Frameworks/AppKit.framework/Headers/NSInputManager.h:25:
warning: previous declaration of ‘-(NSInteger)conversationIdentifier’

Re: nsterm.m warnings

[Jan Djärv]

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 ‘-[EmacsView conversationIdentifier]’:
> nsterm.m:5053: warning: conflicting types for ‘-(long
> int)conversationIdentifier’
> /System/Library/Frameworks/AppKit.framework/Headers/NSInputManager.h:25:
> warning: previous declaration of ‘-(NSInteger)conversationIdentifier’

What do you mean by "both"?  This is only one warning.
It has no practical importance, and only occurs if you build a 32-bit executable, which is rare on OSX.

	Jan D.

Re: nsterm.m warnings

[Carsten Mattner]

On Wed, Jan 4, 2012 at 8:57 PM, Jan Djärv <jan.h.d@swipnet.se> 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 ‘-[EmacsView conversationIdentifier]’:
>> nsterm.m:5053: warning: conflicting types for ‘-(long
>> int)conversationIdentifier’
>> /System/Library/Frameworks/AppKit.framework/Headers/NSInputManager.h:25:
>> warning: previous declaration of ‘-(NSInteger)conversationIdentifier’
>
> 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.

> 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?

Re: nsterm.m warnings

[Jan D.]

Carsten Mattner skrev 2012-01-05 00:49:
> On Wed, Jan 4, 2012 at 8:57 PM, Jan Djärv<jan.h.d@swipnet.se>  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 ‘-[EmacsView conversationIdentifier]’:
>>> nsterm.m:5053: warning: conflicting types for ‘-(long
>>> int)conversationIdentifier’
>>> /System/Library/Frameworks/AppKit.framework/Headers/NSInputManager.h:25:
>>> warning: previous declaration of ‘-(NSInteger)conversationIdentifier’
>>
>> 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 
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 
int on a 32-bit build.  In principle such a conversion can truncate the 
value.  But in this case it does not matter, as long as the value is 
unique within the application (Emacs).  As the build is 32-bit, the 
pointer converted to long is 32-bit to start with.  That long is then 
converted to an int, so there is no truncation.

But it is bad style to change interfaces like this, I'll fix it shortly. 
  I guess it was long at some point in time, and then got changed to 
NSInteger.

	Jan D.

Re: nsterm.m warnings

[Carsten Mattner]

On Thu, Jan 5, 2012 at 8:31 AM, Jan D. <jan.h.d@swipnet.se> wrote:
> The code relies on the fact that the compiler can convert a long to an int
> on a 32-bit build.  In principle such a conversion can truncate the value.
>  But in this case it does not matter, as long as the value is unique within
> the application (Emacs).  As the build is 32-bit, the pointer converted to
> long is 32-bit to start with.  That long is then converted to an int, so
> there is no truncation.
>
> But it is bad style to change interfaces like this, I'll fix it shortly.  I
> guess it was long at some point in time, and then got changed to NSInteger.

Thanks.