Re: Cohen's paper on byte order
From: Bryan Olson (fakeaddress@nowhere.org)
Date: 04/10/03
- Next message: rjh: "Re: Unknown file encryption"
- Previous message: Josiah: "Re: Unknown file encryption"
- In reply to: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Next in thread: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Reply: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Bryan Olson <fakeaddress@nowhere.org> Date: Wed, 09 Apr 2003 22:58:06 GMT
Mok-Kong Shen wrote:
>
> Bryan Olson wrote:
>
>>Mok-Kong Shen wrote:
>> > What does that 'first' in 'low order-bit-first' mean?
>>
>>It means when converting between an octet and a string of eight
>>bits, map the octet's least-significant bit to the strings first
>>bit. As we saw, the MD5 spec specifies the other way - most
>>significant bit first.
>
> Why do you need that notion in the present context?
Because the context is Shen's question, and that's the answer.
> I detailed that there is no problem of ambiguity
> in any mapping of the chunk of 8 bits from its location
> in a file to a variable in one's program under any
> situations (with any weird OS, compiler, etc.)
Shen detailed how to make things not work. His posts are
just full of wrong information, which he doesn't care enough
to correct.
>> > If an 8-bit chunk is input, say, from a file into
>> > a variable in program, all 8 bits are there. What is
>> > then 'first'?
>>
>>It's exactly as I've said before. An octet is an eight-bit
>>unsigned integer. It has a most-significant bit and a least
>>significant bit. It does not a well-defined first bit and last
>>bit.
>
> I don't care whether a chunk of 8 bits in a file has
> the significance of numerical value as an integer or
> not.
As shown, Shen also doesn't care whether what he writes is
true, or whether systems designed along the lines he
advocates will inter-operate.
>> > You mentioned in a previous post of
>> > possible dependence even on compiler. o.k.
>>
>>Specifically, when Shen falsely claimed that C structs have a
>>bit with a lowest address, I pointed out that he was talking
>>nonsense. Layout of bit fields is up to the compiler and C
>>doesn't assume any bit even has its own address.
>
> The following is what I wrote:
>
> As an addendum to my previous post, I like to mention
> that the fact that in C one could define a data structure
> to access the individual bits clearly indicates that
> the physical bits in hardware has a natural numerical
> ordering. Therefore in any 8-bit chunk of hardware
> there is a bit with the lowerest address. This bit is
> clearly the unique candidate to be designated as the
> bit 0 of the chunk in my conviction.
>
> That means I can access the bits in hardware in a
> definite and orderly way. If follows that the bits
> in hardware are not like a mathematical set where
> the elements have no order among them but that
> there exists a certain natural numerical order.
> Note that I didn't say anything about 'address' of
> bits in C.
Shen apparently hasn't bothered reading what he wrote, even as
he quoted himself above. Read his indented quote above. First
sentence show's he's talking about how things work in C. Then
read the next sentence about "a bit with the lowerest [sic]
address".
He just doesn't care.
-- --Bryan
- Next message: rjh: "Re: Unknown file encryption"
- Previous message: Josiah: "Re: Unknown file encryption"
- In reply to: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Next in thread: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Reply: Mok-Kong Shen: "Re: Cohen's paper on byte order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
