On 2022-11-06 23:14, raf via openssl-users wrote:
On Sat, Nov 05, 2022 at 02:22:55PM +0000, Michael Wojcik <Michael.Wojcikatmicrofocus.com> wrote:
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of raf via
openssl-users
Sent: Friday, 4 November, 2022 18:54
On Wed, Nov 02, 2022 at 06:29:45PM +0000, Michael Wojcik via openssl-users
<openssl-users at openssl.org> wrote:
I'm inclined to agree. While there's an argument for backward compatibility,
C99 was standardized nearly a quarter of a century ago. OpenSSL 1.x is
younger than C99. It doesn't seem like an unreasonable requirement.
Would this be a choice between backwards-compatibility with C90
compilers and compatibility with 32-bit architectures?
I don't see how.
It's a question of the C implementation, not the underlying
architecture. A C implementation for a 32-bit system can certainly
provide a 64-bit integer type. If that C implementation conforms to
C99 or later, it ought to do so using long long and unsigned long
long. (I'm excluding C implementations for exotic systems where, for
example, CHAR_BIT != 8, such as some DSPs; those aren't going to be
viable targets for OpenSSL anyway.)
Is there another way to get 64-bit integers on 32-bit systems?
Sure. There's a standard one, which is to include <stdint.h> and
use int64_t and uint64_t. That also requires C99 or later and an
implementation which provides those types; they're not required.
Sorry. I assumed that it was clear from context that I was only
thinking about C90-compliant 64-bit integers on 32-bit systems.
And for some implementations there are implementation-specific
extensions, which by definition are not standard.
And you can roll your own. In a non-OO language like C, this would
be intrusive for the parts of the source base that rely on a 64-bit
integer type.
I suspect that that there are more 32-bit systems than there are
C90 compilers.
Perhaps, but I don't think it's relevant here. In any case, OpenSSL is
not in the business of supporting every platform and C implementation
in existence. There are the platforms supported by the project, and
there are contributed platforms which are included in the code base
and supported by the community (hopefully), and there are unsupported
platforms.
If someone wants OpenSSL on an unsupported platform, then it's up to
them to do the work.
So it sounds like C90 is now officially unsupported.
I got the impression that, before this thread, it was believed
that C90 was supported, and the suggestion of a pull request
indicated a willingness to retain/return support for C90.
Perhaps it just indicated a willingness to accept community
support for it.
I'd be amazed if anyone could actually still be using a
30 year old C90 compiler, rather than a compiler that
just gives warnings about C90. :-)
Regarding C90 compilers, it is important to realize that some system
vendors kept providing (arbitrarily extended) C90 compiler long after
1999. Microsoft is one example, with many of their system compilers
for "older" OS versions being based on Microsoft's C90 compilers.
These compilers did not provide a good stdint.h, but might be coached
to load a porter provided stdint.h that maps int64_t and uint64_t to
their vendor specific C90 extensions (named __int64 and unsigned __int64).
Even worse, I seem to recall at least one of those compilers miscompiling
64 bit integer arithmetic, but working acceptably with the older OpenSSL
1.0.x library implementations of stuff like bignums (BN) and various pure
C algorithm implementations in OpenSSL 1.0.x, that happened to do
everything
by means of 32 and 16 bit types.
As part of our company business is to provide software for the affected
"older" systems, thus desiring the ability to compile OpenSSL 3.x with
options indicating "compiler has no good integral types larger than
uint32_t, floating point is also problematic"
Other major vendors with somewhat old C compilers include a few embedded
platforms such as older ARM and MIPS chips that were mass produced in
vast quantities.
Performance wise, using a newer compiler that implements int64_t etc. via
frequent library calls, while technically correct, is going to run
unnecessarily slow compared to having algorithms that actually use the
optimal integral sizes for the hardware/compiler combination.
I seem to recall using at least one bignum library (not sure if OpenSSL
or not) that could be configured to use uint32_t and uint16_t using the
same C code that combines uint64_t and uint32_t on newer hardware.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
