Am Sat, 02 Jun 2018 06:31:37 +0000 schrieb Atila Neves: > On Friday, 1 June 2018 at 20:12:23 UTC, Kagamin wrote: >> On Friday, 1 June 2018 at 10:04:52 UTC, Johannes Pfau wrote: >>> However you want to call it, the algorithms interpret data as numbers >>> which means that the binary representation differs based on endianess. >>> If you want portable results, you can't ignore that fact in the >>> implementation. So even though the algorithms are not dependent on the >>> endianess, the representation of the result is. Therefore standards do >>> usually propose an internal byte order. >> >> Huh? The algorithm packs bytes into integers and does it independently >> of platform. Once integers are formed, the arithmetic operations are >> independent of endianness. It works this way even in pure javascript, >> which is not sensitive to endianness. > > It's a common programming misconception that endianness matters much. > It's one of those that just won't go away, like "GC languages are slow" > or "C is magically fast". I recommend reading this: > > https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html > > In short, unless you're a compiler writer or implementing a binary > protocol endianness only matters if you cast between pointers and > integers. So... Don't. > > Atila
That's an interesting point. When I said the algorithm depends on the system endianess I was indeed always thinking in terms of machine code (i.e. if system endianess=data endianess you hopefully do nothing at all, otherwise you need some conversion). But it is indeed true that describing conversion as mathematical shift operations + indexing will leave handling these differences to the compilers. So you can probably say the algorithm doesn't depend on system endianess, although a low level representation of implementations will. I guess this is what Kagamin wanted to explain, please excuse me for not getting the point. So in our case, we can obviously use that higher-abstraction-level interpretation and the idiom used in the article indeed works fine in CTFE. So somebody (@Manu?) just has to fix std.bitmanip *EndianToNative nativeTo*Endian functions to use this (probably benchmarking performance impacts). Then std.digest should simply start working or should at least be easy to fix for CTFE support. -- Johannes
