Re:Timing the time it takes to parse time
by larvyde on Thursday October 13, 2016 @07:56PM
(#12705195)
The subtraction isn't the issue, the cast is. the string "2016" is represented by the byte sequence [0x32, 0x30, 0x31, 0x36]. Casting this array to a uint32* in big endian gives you the integer 0x32303136 (or 842019126) while in little endian gives you the integer 0x36313032 (or 909193266).
[ Parent
| on HN ]
Re:Timing the time it takes to parse time
by JoeAltmaier on Thursday October 13, 2016 @11:46PM
(#12706009)
...and subtracting 0x30303030 works to exactly the same effect on either one!
Re:Timing the time it takes to parse time
by larvyde on Saturday October 15, 2016 @04:47AM
(#12713281)
0x32303136 - 0x30303030 = 0x02000106
0x36313032 - 0x30303030 = 0x06010002
how is 0x02000106 the same as 0x06010002?
Re:Timing the time it takes to parse time
by JoeAltmaier on Tuesday October 18, 2016 @10:35AM
(#12734756)
When you show the string in memory order, they are the same. Its the operation on the string that's important, not the way you print the hex byte-order-dependent value. Both become 01 00 01 06
Re:Timing the time it takes to parse time
by larvyde on Wednesday October 19, 2016 @12:48AM
(#12741148)
But we're trying to convert the string "2016" to the integer 2016.
we want to turn the sequence [0x32, 0x30, 0x31, 0x36] (same on both architectures) into [0x00, 0x00, 0x07, 0xe0] in big endian or [0xe0, 0x07, 0x00, 0x00] in little endian. You can't simply perform the same procedure in both architectures since it'll result in a reversed sequence in one of them...