std.digest can't CTFE?

[Manu]

On Fri, 8 Jun 2018 at 11:35, Johannes Pfau via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> 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.

I'm already burning about 3x my reasonably allocate-able free time to
DMD PR's...
I'd really love if someone else would look at that :)

I'm not quite sure what you mean though; endian conversion functions
are still endian conversion functions, and they shouldn't be affected
here.
The problem is in the std.digest code where it *calls* endian
functions (or makes endian assumptions). There need be no reference to
endian in std.digest... if code is pulling bytes from an int (ie,
cast(byte*)) or something, just use ubyte[4] and index it instead if
uint, etc. I'm surprised that digest code would use anything other
than byte buffers.
It may be that there are some optimised version()-ed fast-paths might
be endian conscious, but the default path has no reason to not work.