On Fri, 2022-11-11 at 16:01 +0100, Jakob Bohm via openssl-users wrote: > 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. That ship has sailed long long time ago. And it is NOT about the BIGNUM type implementation which definitely supports native 32bit BN_WORD. Although it might be possible to avoid using 'long long' or 'unsigned long long' with some patching, the int64_t/uint64_t support is absolutely required in other parts of OpenSSL than BIGNUM library and I do not see any reasonable way to avoid it at all. Yeah current OpenSSL library is definitely not a crypto library that targets constrained 32 bit platforms that do not support 64 bit integers. -- Tomáš Mráz, OpenSSL
