<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - support for digital signatures" href="https://bugs.freedesktop.org/show_bug.cgi?id=16770#c77">Comment # 77</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - support for digital signatures" href="https://bugs.freedesktop.org/show_bug.cgi?id=16770">bug 16770</a> from <a class="email" href="mailto:adam.reichold@t-online.de" title="Adam Reichold <adam.reichold@t-online.de>"> Adam Reichold</a> <pre>(In reply to Andre Guerreiro from <a href="show_bug.cgi?id=16770#c76">comment #76</a>) > Created <a href="attachment.cgi?id=118745" name="attach_118745" title="Incremental hashing + large file support">attachment 118745</a> <a href="attachment.cgi?id=118745&action=edit" title="Incremental hashing + large file support">[details]</a> <a href='page.cgi?id=splinter.html&bug=16770&attachment=118745'>[review]</a> [review] > Incremental hashing + large file support > > With this patch I've implemented the incremental hashing plus the large file > support. > > This is still untested with files larger than 2GB but is correct for all the > regular test cases I gathered before. Some minor suggestions: * The naming of BLOCK_SIZE and block_len in hashSignedDataBlock seems misleading to me, maybe CHUNK_SIZE and block_len? * The method hashSignedDataBlock could probably be replaced by a static function taking the stream and the handler? This should give the compiler more optimization possibilities than if it is visible in other translation units. * I think the while loop within could become a for loop for better readability with the case reduced to computing the number of bytes to read instead of two separate calls to doGetChars and updateHash.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>