>aByte >> 32
>aByte << 32
>
>both ALWAYS return 0. Is that what you intended?

Nope, but you just pointed out something that appeared to work for 
me. For I never encountered any problems with it -- apparently I was 
lucky. I also, used:

LOCAL FN readReal    'read 6 bytes long integer in LSB order
DIM a!
a! = (FN readByte) + (FN readByte <<8) + (FN readByte <<16) + (FN 
readByte <<32) + (FN readByte <<64) + (FN readByte <<128)
END FN = a!

So, I guess that that function didn't work correctly either? Again, I 
never encountered any errors and everything worked as it should. The 
program was a "Street Atlas" type program and any errors would have 
stood out like a sore thumb and there wasn't any -- truthfully. 
Understand that I was dealing with over 750 megs of doubly compressed 
data (logical and zip compression) and it never failed. I wonder why?

>I can't see any reason for your byte-by-byte approach except to eat up
>processor time.
>
>  e-e
>  =J= a  y

The reason was that I had very large files that consisted of several 
different data types (i.e.,  byte, unsigned byte, signed byte, 
integer, medium integer, long integer and real) which were all strung 
together in no specific order or sequence.

The only way to tell what was happening was to read the first byte of 
each data set/record which then set what followed. So reading the 
file byte by byte made sense to me. In fact, one HAD to read the file 
in a byte by byte approach to find the record type. Of course, after 
finding the record type, I could have then read the records as the 
data type presented itself, but it was easier for me to understand to 
keep it at the byte level. Apparently your mileage varies. Please 
understand I can only do what I can with what I got.

tedd

-- 
http://sperling.com