 |
lua-l archive |
|
|
||
|
Am 10.07.2013 16:46 schröbte Doug Currie:
On Jul 10, 2013, at 5:14 AM, Philipp Janda <siffiejoe@gmx.net> wrote:`^` is only taken for numbers, but IMHO it doesn't make much sense to define bit operations on numbers anyway: "Let's take the number of apples and xor it with the number of oranges, right shift by the number of baskets, and we get: total nonsense"! Usually one does arithmetic _xor_ bit manipulation at any given time[*].Besides the hash table exception you noted, there are also encryption, digital signatures, and hash (message-digest) applications.
I know of arithmetic in asymmetric encryption, but those are big integers (more than 64 bits). Other than that: encryption transforms a stream of bytes into another stream of bytes, while cryptographic hashes transform byte streams into bit strings or hex strings. From the outside I cannot see any numbers, so I assume that some arithmetic operations (`+` and `*`, mostly) are performed on some internal state, usually on fixed width unsigned integers with wrap around semantics, i.e. uint64_t, uint32_t, uint8_t and maybe uint16_t (if you decompiled the C source code you would probably find some arithmetic on 128+ bit unsigned "numbers" somewhere).
Am I wrong?In C you can do arithmetic on pointers, characters, enumerations, and "booleans". Just because someone does `+` and `*` on something in C code doesn't mean it's (supposed to be) a number. I can appreciate, that bit operations are used to implement arithmetic on numbers, but applying bit operations to numbers or applying arithmetic operations to bit containers seems like nonsense to me. I usually get suspicious when an algorithm requires the wrap around semantics of C's unsigned integers. For numbers, wrap around doesn't make particular sense (for non-primes). It only starts to make sense when you consider the bit representation ...
e
Philippp.s.: Already found the fake 128 bit unsigned numbers in libapr's SHA2 implementation ...