Hi Everyone, Some distributions test the library using an unstable platform/distribution that provides unstable tools. This is sometimes referred to "bleeding edge". Though its called "unstable" or "bleeding edge", its should not be received in a negative way. Its simply cutting edge, and its paving the way for the next release cycle.
We have taken a few bug reports under the unstable testing. The reports are usually an unexplained failure, like a hang or crash. From our Release Testing process (http://cryptopp.com/wiki/Release_Testing), I'm fairly confident of the code. I don't claim its bug free, but the assurance levels are fairly high. We can't get access to the testing environment where the finding is produced. Some times, the test rig (bleeding edge platform and tools) is so delicate that we can't set it up to duplicate the issue. For example, it may be a particular version/check-in of the tools, and when we perform an "apt-get update/upgrade cycle, we skip over the problem package. As an example, there was a hang in SHA in bleeding edge when ASM was in effect. We was not able to reproduce it or access the test environment, and eventually a VM was TAR'd and made available for us. By disabling ASM or moving ResizeBuffers() out-of-line, we cleared a hang and a crash (see http://github.com/weidai11/cryptopp/pull/46/files). And as soon as we updated the toolchain in the VM, the issue resolved itself. Wei suggested we disable ASM, but I [mildly] disagree. My opinion differs because I still see benefit to the code. First, the code is genuinely faster than what the compiler produces. I doubt the compiler will ever be able to produce faster AES or Whirpool code than a human when CPU acceleration is available. Second, we have to use ASM for down level toolchains, like Visual Studio 2005, when using instructions like RDRAND and RDSEED. Though the instructions are fairly recent (circa 2012/2013), we can still produce usable code in Visual Studio 2005 that utilizes the instructions. I'd like to solicit feedback regarding a reasonable strategy when working with unstable platforms or tools. That is, what should our policy be? Below are some examples to help get you pointed in the right direction. I'm just tossing them out there as examples. I'm not showing my hand yet because I don't want to influence the process. Jeff Potential Strategies * Don't support unstable; only support stable * Don't support unstable+ASM; require CRYPTOPP_DISABLE_ASM * Fully support unstable -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
