Timeline for Incremental sha256sum computation
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 2, 2018 at 19:31 | comment | added | chux |
I disagree that struct ctx_t member uint64_t msglen; should be size_t. That should remain uint64_t. OTOH in sha256_update (ctx *c, const uint8_t *msg, const uint64_t msglen) should use size_t msglen
|
|
| Dec 30, 2017 at 23:51 | comment | added | vnp |
@DavidC.Rankin Your implementation of min looks good. I don't think you should worry about branch prediction. It seems to be peanuts compared to the amount of work done by sha256hashblock. If you are OK with gcc specifics, __builtin_expect(msglen > chunk, 1) may help. Of course, profiling is necessary.
|
|
| Dec 30, 2017 at 23:33 | comment | added | David C. Rankin |
Thank you. I like the sha256_update cleanup, and had planned a revisit. The difficulty I find depends on how min is implemented. If implemented as a macro, subtraction gives rise to a warning of comparison between signed and unsigned types. If implemented as a function, then a type specific min is needed. I have settled for uint8_t chunk = DGST256 - c->blklen; followed by an if (chunk > msglen) chunk = msglen;, but am left wondering whether or how to improve branch prediction of the test? That gets rid of the req (required) and off (offset) mirror. The while is cleaner.
|
|
| Dec 30, 2017 at 20:04 | history | answered | vnp | CC BY-SA 3.0 |