At 10:53 PM 8/7/00 +0200, Bart Lateur wrote:
Right. Why you people don't call it "Intel" vs. "Motorola", like the
rest of the civilised world, I don't know. ;-) See the TIFF spec, for
example.
Er, in case you were in any doubt: Motorola (from the 68k processors) is
BigEndian, Intel (x86) is
At 07:26 PM 8/7/00 +0100, Tom Hughes wrote:
From /usr/include/endian.h on my linux box:
#define __LITTLE_ENDIAN 1234
#define __BIG_ENDIAN4321
#define __PDP_ENDIAN3412
Basically PDP or middle endian is low byte first within each word
but high word first in the overall longword.
This,
On Mon, 7 Aug 2000 13:52:09 -0400, John Porter wrote:
Right, VAX is strictly little-endian.
I.e. the address of a *word is the address of its least significant byte.
(That's little-endian, isn't it?)
Right. Why you people don't call it "Intel" vs. "Motorola", like the
rest of the civilised
In message [EMAIL PROTECTED]
Edwin Wiles [EMAIL PROTECTED] wrote:
Endianness:
/d - default, whatever your system uses normally
/n - network
/b - big
/l - little
/v - vax
(??vax is sufficiently different to require it's own?? Or is this to do
with bit order?)
VAX is either
Glenn, et.al.
I'm going to be combining a number of different comments in here.
Glenn Linderman wrote:
I was surprised by the read/write operations, but have no objection to them.
New/get/set and the individual data member access functions are the critical
pieces, as the I/O could be done to
Edwin Wiles wrote:
Without them, the programmer must calculate the required length of the reads
themselves.
Good point. I now want them, rather than being ambivalent.
[ 'bar' = 'i', 'baz' = 'i', 'count' = 'i' ]
It is my understanding that "=" is an indication of a link in a hash
Bart Lateur wrote:
On Wed, 02 Aug 2000 12:22:09 -0700, Glenn Linderman wrote:
[ 'bar' = 'integer32', 'baz' = 'integer32', 'count' = 'integer32' ]
[ 'var1' = 'int32', 'var2' = 'int16', 'var3' = 'int8' ]
That doesn't reconsider BigEndian vs. LittleEndian, AKA pack/unpack 'N'
vs.
The existing pack and unpack methods are dependent upon a
simple yet complex 'format' structure, which is often
difficult to get right, and which carries no information
regarding the associated variable names.
I know what you mean, but it reads like "black yet
Edwin,
This writeup certainly is a great first draft for this RFC. I'll have to track down
those references.
I was surprised by the read/write operations, but have no objection to them.
New/get/set and the individual data member access functions are the critical pieces,
as the I/O could be
