Re: looks like Intel vs. PowerPC difference

FROM : Matt Neuburg
DATE : Thu Aug 03 20:53:15 2006

On Thu, 3 Aug 2006 14:22:54 -0400, Andrei Tchijov <<email_removed>> said:
>Very true.  It just that I got bitten by it (I did not assigned
>initial values to in/out stream). Nowhere in the documentation it
>mentions that you have to nil initial values in order to be able to
>check success/failure.  It looks little bit odd to me.  Why this
>method does not return some sort of status is quite beyond  me.
>
>To be fair, documentation does not promise that in/out stream
>variables will be nil-ed on failure.


I have to say that I agree with Sherm on this. It isn't just this call. I
have recently rewritten ALL my code where there is a double-pointer like
this whose value I am going to check afterwards, and guess what - when I
supply a known value (e.g. nil) at the outset, a bunch of mysterious
misbehaviours went away. Example:

    NSError* err = nil; // <--- LOOK!
    NSXMLDocument *xmlDoc = [[NSXMLDocument alloc]
      initWithContentsOfURL:url options:0 error:&err];
    [xmlDoc autorelease];
    if (err) // etc.

In other words, if this is not your habit *every* time you are in this
situation (not just for this call), then the fact that you have not been
bitten before is just chance.

Another way of putting it is: assume nothing, especially when it is so
simple to make no assumptions at all.

Another way of putting it is: ivar pointers are auto-initialized to nil, but
pointers in your code are not (something that I am constantly forgetting,
personally...) m.

>
>On Aug 3, 2006, at 2:04 PM, Sherm Pendley wrote:
>

>> On Aug 3, 2006, at 1:37 PM, Andrei Tchijov wrote:
>>

>>> It looks like
>>>
>>> +[ NSStream (void)getStreamsToHost:(NSHost *)host port:(int)port
>>> inputStream:(NSInputStream **)inputStream outputStream:
>>> (NSOutputStream **)outputStream ]
>>>
>>> works slightly different on Intel, compare to PowerPC.  On
>>> PowerPC, when this method fails, it will set inputStream/
>>> outputStream to nil.  It looks like on Intel, in case of failure,
>>> it leaves inputStream/outputStream untouched.

>>
>> That sort of internal detail shouldn't make a difference in how you
>> use this method.
>>
>>  NSInputStream *inStream = nil;
>>  NSOutputStream *outStream = nil;
>>
>>  [NSStream getStreamsToHost:someHost port:somePort
>> inputStream:&inStream outputStream:&outStream];
>>
>> What effective difference can it possibly make whether
>> +getStreams... method explicitly set either inStream or outStream
>> to nil, or simply left the existing nil value alone? Either way the
>> result will be the same - nil on failure.
>>
>> sherm--
>>
>> Web Hosting by West Virginians, for West Virginians: http://wv-www.net
>> Cocoa programming in Perl: http://camelbones.sourceforge.net
>>
>>

>
>
>
>


--
matt neuburg, phd = <email_removed>, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>