std.digest can't CTFE?

[Johannes Pfau]

Am Fri, 08 Jun 2018 11:46:41 -0700 schrieb Manu:
> 
> 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'll see if I can allocate some time for that. Should be a mostly trivial 
change.

> I'm not quite sure what you mean though; endian conversion functions are
> still endian conversion functions, and they shouldn't be affected here.

Yes, but the point made in that article is that you can implement 
*Endian<=>native conversions without knowing the native endianness. This 
would immediately make these functions CTFE-able.

> 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.

That's not how hash algorithms are usually specified. These algorithms 
perform bit rotate operations, additions, multiplications on these 
values*. You could probably implement these on byte[4] values instead, 
but you'll waste time porting the algorithm, benchmarking possible 
performance impacts and it will be more difficult to compare the 
implementation to the reference implementation (think of audits).

So it's not realistic to change this.

* An interesting question here is if you could actually always ignore 
system endianess and do simple casts when cleverly adjusting all 
constants in the algorithm to fit?
-- 
Johannes