These changes, together with the changes to the Configure script found
in ticket #1129, constitute the total set of changes needed to get
OpenSSL 0.9.8-beta5 to build and run its self-tests on the Stratus V
Series (Intel IA32) platform. They are not needed for the Stratus
Continuum (PA-RISC) platform. I tested these changes on a V400
running VOS Release 15.1.0ah. I also successfully tested the same
changes on an Intel Pentium III running RedHat Fedora Core 1 (a native
little-endian IA32 platform), just to have some confidence that I had
not messed-up the underlying platform and endian independence.
Quoting sha_local.h before suggested change:
# ifdef SHA1_ASM
# if defined(__i386) || ...
...
# elif defined(__ia64) || ...
...
# endif
# endif
and after applying submitted patch:
# ifdef SHA1_ASM
# if !defined(B_ENDIAN)
# if defined(__i386) || ...
...
# elif defined(__ia64) || ...
...
# endif
# endif
# endif
If IA32 was the only one being tested, why was IA64 affected by the
suggested change? For reference, [all] our IA64 modules are maintained
endian-neutral. Furthermore. Note that this is protected by #ifdef
SHA1_ASM, which is *not* defined on VOS, meaning that suggested change
was never actually tested on the target platform. If so, why it was
called "patches *for* Stratus VOS":-) Same applies to corresponding #if
[MD5|RMD160]_ASM clauses...
Another fishy thing. In md32_common.h you suggested to add #ifndef
B_ENDIAN in DATA_ORDER_IS_LITTEL_ENDIAN part, but not in
DATA_ORDER_IS_BIG_ENDIAN. I wonder how come the latter didn't break on
your platform? As you mentioned yourself VOS gcc supports inline
assembler and neither OPENSSL_NO_ASM nor OPENSSL_NO_INLINE_ASM gets
defined by default... In otder words it should have break... Can you
shed some light?
Richard Levitte via RT wrote:
As an editorial comment, I would like to respectfully suggest that in
the future, platform tests (#ifdef __IA32__) be used to establish
attributes or qualities, and that the mainline source code test the
attributes or qualities. The current source code tests __IA32__ and
related macros for several different reasons (e.g., instruction set,
endianness, alignment requirements, etc.) Having it test attribute or
quality names would have been much more transparent.
We do some tests like that, but using OpenSSL specific macros generated
from the system name field in the configuration strings. This is
because we (or at least I) have run into trouble where different
compilers support differents sets of flag macros for the same kind of
function. It kind of gets out of hand...
... because it takes too much discipline. We don't need to go far for
example. Take just posted "[PATCH] OpenSSL for Windows Mobile 2003" for
example, where we can read
-#if ... !defined(OPENSSL_SYS_WINCE)
+#if ... !defined(OPENSSL_SYS_WINCE) && !defined(PPC2003)
As far as I understand PPC2003 runs Windows CE... Yes, we can blaim them
for "not having the discipline(*)" to see the obvious and demand that
they define OPENSSL_SYS_WINCE... Or we could we have relied on
pre-defined _WIN32_WCE and use the remaining energy on being
creative/productive elsewhere. Note that it's perfectly safe to rely on
_WIN32_WCE here, because the first "if" is _MSC_VER.
As for #ifdef __i386. Trouble is that there're just too many
IA32/gcc-based platforms (not to mention that they *all* are
little-endian:-), which naturaly requires a lot of [synergy] discipline
to maintain multivalue OS/CPU matrix if we choose to totally switch to
own macros. And we would have to accept that own macros limits and makes
it hard/trickier to reuse code in alternative context.
In other words my position is that if vendor [or widely-accepted
de-facto standard] pre-defines are reliable enough to identify 99% of
platform, I wouln't hesitate to prefer them and spare productivity for
something else. Cheers. A.
(*) Please! Note that the expression "not having the discipline" is used
*solely* to clarify/emphasize the meaning of "discipline" mentioned in
the beginning of the rant and should not be taken literally.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
