> 1. "This may result in erratic program behavior, > including memory access errors..." in which case > 3. Program termination (a crash),..", which will
How do you plan tests for this? How would you know what kind of input to use for your test that will cause any of those behaviors? The only way you can know it in advance is by doing a source code audit, or if you prefer, disassemble the program and reverse engineer it. Or maybe if you one of those machines used by security research groups that feed random gibberish to a machine until a crash occurs. Unfortunate, this kind of test will take months or years. Are you aware that carefully crafted buffer overrun exploits don't exhibit any of those behaviors? > 2. "incorrect results..", This will be caught also by Which can only be detected by manual comparison. In deployment, if the machine is compromised, you'll need to check whether machine's tally matches manual counting. > 4. " or a breach of system security" meaning absurd or > corrupt results will be generated. The Outcome test You can breach the security of a machine and make it seem there is no data corruption. And again, the only way to verify is to do a manual counting. _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List http://lists.linux.org.ph/mailman/listinfo/plug Searchable Archives: http://archives.free.net.ph
