an oldie but a goodie .. ISO C90 does not support 'long long'

[Tomas Mraz]

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