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. :-) > -- > Michael Wojcik cheers, raf
