> David seems to be thinking ahead into the realms of CPUs that have not > been invented yet.
Exactly. That's why there are standards and guarantees. If you follow the standards and rely on the guarantees you have, your code will work on all future platforms that provide those same guarantees you have. At one time, the idea that a compiler would enforce the C standard's aliasing rules was inconceivable. Did a lot of code break on newer compilers that relied on them in optimization? Yes, it did. At one time, the idea that a CPU would reorder writes that had been placed in order in assembly code was inconceivable. Did some code break on newer CPUs that had posted write buffers? Yes, it did. > I'm don't give two hoots about those CPUs and I > certainly wouldn't waste brain cells trying to make my code portable to > a piece of hardware that does not exist. Forgive me for being blunt, but that's a totally idiotic attitude. I for one don't expect to have to recompile or even debug my software when I upgrade my CPU. It is unreasonable to design code so that it breaks on new CPUs, and when you rely on behavior that is not documented or guaranteed, that's exactly what happens. I understand that you think that this one assumption is safe and won't break. But I can tell you from a long history of such assumptions that they are *not* safe and they *do* break. Can I tell you how and when this particular one will break? No, I can't. Have I seen many similar assumptions break in the past? Yes, I have. I have worked as a professional programmer for more than 20 years and have worked directly for or consulted for about 8 companies that develop software as a primary or significant aspect of their business. This type of code violates the published coding standards of the six of those companies that have them. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
