Basically this discussion applies even to tickets #3422 and #3423. This means that I'm not going to comment on those tickets, but do whatever we agree on doing here and close them simultaneously.
> I think the main question is if this speed difference is a good > excuse to use undefined behavior or not. As already mentioned, the difference depends on how fast is cipher. As cbc128.c is not cipher-specific, you can't pose question about "*this* difference". Well, we can assess current ciphers and say "too little", but then we would have to reconsider for each new cipher we add. Or we simply consider this kind of optimization acceptable or not without quantifying. Just in the context of this warning. I brought up quantitative difference only to expose mislead conclusion. And I argue yes, it's justifiable. And as compromise, suggestion is to avoid it in -DPEDANTIC build. So instead of rephrasing question, tell what conclusion do you draw. To recap. Original statement was "I have no problem based on this data". "But the data is flawed". "Yes, indeed". And conclusion is? [And reply to <[email protected]>]. As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to this one, second is about variable shift in CAST. As mentioned they all are conscious choices and are proven to work. BTW, specification gives following example of undefined behaviour: "EXAMPLE: An example of undefined behavior is the behavior on integer overflow." Well, one can argue about definition of "integer", but if we assume "any integer, signed or unsigned", then we depend on unsigned addition being non-saturating and overflow being ignored *all* *over* *the* *place*... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
