On 29/12/2018 17:18, C.Wehrmeyer wrote:
On 29.12.18 17:21, J. J. Farrell wrote:> So instead of correct
portable code which derives obviously and
> straightforwardly from the specification, you'd write arrays of a
> different length from the original, the first 48 bytes of which would
> only be correct in some compilation environments, and even in the cases
> where those 48 bytes end up correct they have no obvious
relationship to
> the specification they are implementing (your obfuscation making the
> code much more difficult to review). How are these changes improvements?
Another implication, this time that my code isn't perfectly portable
code. There is *one* environment I could think of where this wouldn't
be the case - that being Shift JIS environments that tinker with ASCII
standard by replacing a backslash with a Japanese half-width Yen sign
- however:
1. we'll already have much, MUCH bigger problems if ASCII isn't the
encoding the compiler is expecting here, so exchanging 0x5c for '\' is
not going to ruin much more here. And it doesn't even matter anyway
because any Shift JIS editor would display this as ...
You don't explain the benefits of coding a requirement for "the byte
0x5C repeated 48 times" as a string of back-slash characters instead of,
well, the byte 0x5C repeated 48 times. What are the benefits, and how do
they outweigh the ability to compare more easily against the requirement?
You don't explain the benefits of writing non-portable code where that
code is very widely deployed in environments of which you have no
knowledge (and which don't even exist at the time of writing it),
without even a comment specifying the portability restrictions you are
imposing, when it's just as easy to write the code portably and not need
to think about such restrictions. What are the benefits, and how do they
outweigh the obvious disadvantages?
--
J. J. Farrell
Not speaking for Oracle
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
