Submitting patches¶

You've found a bug or missing feature in the cracker and written some code to fix it up. Great - what now? If you'd like to share your work, please email a patch to Andrew Zonenberg, the lead developer. To increase the chances of your patch being accepted, please follow the guidelines below:

• First and foremost, buggy patches, including those which break existing functionality, will not be accepted! Please test your code thoroughly, using unit tests if available for that part of the code. Run several cracks using different algorithms, lengths, and character sets, and ensure things work as expected. While we recognize that no programmer is perfect, we do expect a reasonable degree of effort.

• This is a cross-platform project. Try, within reason, to avoid using OS-specific system calls; if this is unavoidable use the appropriate #ifdefs and provide alternative code for other systems (or at least gracefully degrade to the previous functionality). Patches which break the cracker on any platform WILL be rejected.

• Use the same formatting conventions as the rest of the project. Having one file using ANSI bracing and another using K&R bracing - or, worse yet, mixing the styles in a single source file - results in awkward and hard-to-read code.

• Patches should be made against the latest Git HEAD rather than an earlier version of the source such as our downloadable tarballs. This will reduce the chances of your patch conflicting with recent changes.

• Patches may be submitted for new features or those which are not listed as assigned in the issue tracker. If you would like to help out on an issue which is listed as assigned, please contact the user it is assigned to directly.