5 ms·

Which part are you referring to? Bit operations etc isn't affected by endianess. It looks like it would only potentially be a problem if input is coming from an

by dimman 10y ago

Which part are you referring to? Bit operations etc isn't affected by endianess. It looks like it would only potentially be a problem if input is coming from another system (haven't looked at where input comes from or what format/type).

avian 10y ago
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.
- JoeAltmaier 10y ago
  Regardless of layout, that subtraction will have the same effect on most printable characters. An identical effect on digits.
  - avian 10y ago
    The cast is the problematic part, not the subtraction.
    - JoeAltmaier 10y ago
      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.
      - huhtenberg 10y ago
        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.
        zeusk 10y ago
        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.
      - larvyde 10y ago
        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).
        JoeAltmaier 10y ago
        ...and subtracting 0x30303030 works to exactly the same effect on either one!
        larvyde 10y ago
        0x32303136 - 0x30303030 = 0x02000106 0x36313032 - 0x30303030 = 0x06010002 how is 0x02000106 the same as 0x06010002?
        JoeAltmaier 10y ago
        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
        larvyde 10y ago
        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...
- deleted 10y ago
  [deleted]
to3m 10y ago
Y>>24 will be the byte at +3 on a little-endian system, or +0 on a big-endian system. It's therefore the digit in the 10^0 column in the former case, or the 10^3 column in the latter. So it actually looks like it currently assumes a big-endian system.

by dimman 10y ago

avian 10y ago

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.

JoeAltmaier 10y ago
Regardless of layout, that subtraction will have the same effect on most printable characters. An identical effect on digits.
- avian 10y ago
  The cast is the problematic part, not the subtraction.
  - JoeAltmaier 10y ago
    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.
    - huhtenberg 10y ago
      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.
      - zeusk 10y ago
        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.
    - larvyde 10y ago
      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).
      - JoeAltmaier 10y ago
        ...and subtracting 0x30303030 works to exactly the same effect on either one!
        larvyde 10y ago
        0x32303136 - 0x30303030 = 0x02000106 0x36313032 - 0x30303030 = 0x06010002 how is 0x02000106 the same as 0x06010002?
        JoeAltmaier 10y ago
        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
        larvyde 10y ago
        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...
deleted 10y ago
[deleted]

to3m 10y ago

Y>>24 will be the byte at +3 on a little-endian system, or +0 on a big-endian system. It's therefore the digit in the 10^0 column in the former case, or the 10^3 column in the latter. So it actually looks like it currently assumes a big-endian system.