Talk:MD5/Implementation: Difference between revisions
→Off-site code
| (6 intermediate revisions by 2 users not shown) | |||
Line 20:
: I would like to see a counterpart task, where calling out to an external implementation is a requirement of the task. Then we can migrate the original code examples and retire [[MD5]]. Otherwise, we've just crufted task and created unnecessary overlap. --[[User:Short Circuit|Michael Mol]] 11:46, 5 October 2010 (UTC)
:: Mike I created this in part because I was told that the other task was too old to change. I was going to remove my code from the old task and point here. I'm for it BTW but it needs to be precisely defined. We already have tasks that call other languages, system routines, etc. How would the other MD5 task be different? What's to stop someone from calling the code they wrote here? What would be wrong with that? Just a thought. --[[User:Dgamey|Dgamey]] 21:25, 5 October 2010 (UTC)
::: If they would ''really'' use their own pure-language implementation of MD5, then there's nothing implicitly wrong with linking to the code over here, as long as long as the "unimplemented in X" requirements are met. That's my primary concern. I'm going to back off on this, though, because every time I try to think through this, I second-guess myself, and I've got too much at work on my plate already. My reply in [[Talk:MD5]] was intended to be explanatory on the history of policies on external libraries, not as a statement on whether or not tasks could be changed or deprecated. --[[User:Short Circuit|Michael Mol]] 22:17, 5 October 2010 (UTC)
== Off-site code ==
Line 46 ⟶ 47:
:::::* An implementation taken from a native source library is acceptable only if it is shown (in detail) on this site.
::::Or am I completely off base here? --[[User:Rdm|Rdm]] 12:44, 5 October 2010 (UTC)
::::: I don't understand the distinction. --[[User:Short Circuit|Michael Mol]] 02:34, 6 October 2010 (UTC)
::::: Neither did I but it is now very clear. --[[User:Dgamey|Dgamey]] 18:57, 6 October 2010 (UTC)
:::::: One case in point, one of the original MD5 tasks (Autohotkey?) is largely coded natively but uses a couple of callouts for minor functions. I would take this as largely meeting the intent of the task as it still shows bit manipulation, etc., etc. --[[User:Dgamey|Dgamey]] 18:57, 6 October 2010 (UTC)
:::::: The distinction is that the first is permissive -- it accepts an implementation on this site for that case, but does not prohibit alternatives (RFC 2119 "MAY" or "SHOULD"). My proposed revision prohibits alternatives (RFC 2119 "MUST"). --[[User:Rdm|Rdm]] 20:48, 12 October 2010 (UTC)
=== Gimmie for C? ===
Given that the IETF reference implementation is written in C, should C get a gimmie and use a link to the code? --[[User:Dgamey|Dgamey]] 21:33, 5 October 2010 (UTC)
: No; the fundamental approach of the site is in-line visual comparison of code. Links off-site break that. --[[User:Short Circuit|Michael Mol]] 02:33, 6 October 2010 (UTC)
===Compatible licensing?===
Line 80 ⟶ 87:
::Acknowledged verbatim. --[[User:Dgamey|Dgamey]] 10:40, 5 October 2010 (UTC)
== Debugging - Pseudo Code is not enough ==
Because hash functions are designed to thoroughly mix their inputs, even a small error will result in a completely different hash. A single bit change should result in half the bits of the digest changing. So if you encounter errors in your implementation you will likely need to break down constants, each step, sub-function, and round to find the error.
| |||