News for hackers. Stuff that matters.

A comment on Timing the time it takes to parse time. Parent comment

Re:Timing the time it takes to parse time by avian on Thursday October 13, 2016 @09:16AM (#12700520)
I was referring to this part:

    Y = *(uint32_t*)s - 0x30303030;
By casting a string to a uint32_t, you are assuming the memory layout of uint32_t. Y will have a different value depending on architecture. E.g. on a typical little-endian you will get 0x06010002. On big-endian you will get 0x02000106.

I'm talking about C, however. I didn't notice the post is talking about C#. Things might be better defined there.

[ Parent | on HN ]
Re:Timing the time it takes to parse time by JoeAltmaier on Thursday October 13, 2016 @09:27AM (#12700585)
Regardless of layout, that subtraction will have the same effect on most printable characters. An identical effect on digits.
[ Parent | on HN ]
Re:Timing the time it takes to parse time by avian on Thursday October 13, 2016 @09:38AM (#12700660)
The cast is the problematic part, not the subtraction.
[ Parent | on HN ]
Re:Timing the time it takes to parse time by JoeAltmaier on Thursday October 13, 2016 @09:53AM (#12700749)
If there is no carry, then I don't understand. Four bytes will have the same value deducted. regardless of the byte order. If there is no carry implication (all are digits) then there is no issue.
[ Parent | on HN ]
Re:Timing the time it takes to parse time by huhtenberg on Thursday October 13, 2016 @09:58AM (#12700780)
On RISC platforms

  *(uint32_t*)s
will get you a SIGBUS if s is not aligned to a 4-byte boundary. Though that's another issue, not what OP was referring to.
[ Parent | on HN ]
Re:Timing the time it takes to parse time by zeusk on Thursday October 13, 2016 @02:40PM (#12703014)
ARM has unaligned access since v6 (introduced in 2001); if you're on linux, unaligned access will be patched by the kernel (as was the case prior ARMv6 and even for MIPS afaik).

Anyway, the point of his post was about possible gains from removing validation, not about being portable or production code.

[ Parent | on HN ]
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!
[ Parent | on HN ]
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?

[ Parent | on HN ]
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
[ Parent | on HN ]
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...

[ Parent | on HN ]