Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
- Subject: Re: Is there a more efficient way to get the first 4 bytes off a NSInputStream to compare
- From: Adam Venturella <email@hidden>
- Date: Tue, 27 Jan 2009 06:23:08 -0800
Will thanks for the heads up, for my purposes this time around, the
input stream will be coming in off the file system, but I did not want
to load the whole thing into an NSData object.
Graham, thanks for the byte-ordering nod as well. The file I am
reading is assured to be in little-endian, and I am checking what the
host byte ordering is first. Leopard is little endian ( at least on
the intel chips, but I have read there are other macs that are
big-endian, so I am trying to catch and handle that accordingly)
With regard to how the casting is actually working, I just want to
make sure I understand the logic:
uint key = *(uint*)&buffer;
from right to left this is what is happening:
Get a pointer/reference to 'buffer'. Cast that pointer into a uint
pointer. Then, dereference the pointer to get it's value.
Is that correct?
On Tue, Jan 27, 2009 at 2:57 AM, William Jon Shipley
<email@hidden> wrote:
>> [inputStream open];
>> [inputStream read: buffer maxLength:sizeof(buffer)];
>
> ...
>
> Note that although your call to -read:maxLength: will work as you expect
> most of the time, it's not guaranteed to work and is bad practice.
>
> The docs for NSInputStream say this method will "Return the actual number of
> bytes placed in the buffer" - eg, you're not promised that you'll get all
> the bytes, just at least 1 byte.
>
> Consider a case where the inputStream represents a TCP/IP socket, and the
> far side has sent one byte, then got delayed for a minute (or longer), then
> sent the final three. It's not documented how many bytes you'll get from
> your call - you could get just one, immediately, or all four, after a
> minute.
>
> In general, when reading from a network socket, you need to call your read
> methods in a loop: you attempt a read, check to see if you have all the
> data, and if not read some more. (The same goes for write methods.)
>
> This is complicated by NS{In,Out}putStreams not having a timeout (that I can
> find), and it's not clear to me from the documentation whether and when they
> block waiting for input to arrive (or room to be made on the output buffer).
>
> There is, however, an example at
> http://developer.apple.com/samplecode/CocoaEcho/listing3.html which appears
> to be written correctly. It's unfortunately a lot of code right now.
>
> -Wil
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden