Re: an oldie but a goodie .. ISO C90 does not support 'long long'
On 2022-11-15 21:36, Phillip Susi wrote: Jakob Bohm via openssl-users writes: 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. Why would you think that? If you can rewrite the code to break things up into 32 bit chunks and handle overflows etc, the compiler certainly can do so at least as well, and probably faster than you ever could. When a compiler breaks up operations, it will do so separately for every operation such as +, -, *, /, %, <<, >> . In doing so, compilers will generally use expansions that are supposedly valid for all numbers, while manually breaking up code can often skip cases not possible in the algorithm in question, for example taking advantage of some values always being less than SIZE_T_MAX. Also, I already mentioned that some compilers do the breaking incorrectly, resulting in code that makes incorrect calculations. 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
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
Jakob Bohm via openssl-users writes: > 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. Why would you think that? If you can rewrite the code to break things up into 32 bit chunks and handle overflows etc, the compiler certainly can do so at least as well, and probably faster than you ever could.
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
Jakob Bohm wrote in <5257e6e7-94e3-896d-73c8-9c17b29b8...@wisemo.com>: |On 2022-11-06 23:14, raf via openssl-users wrote: |> On Sat, Nov 05, 2022 at 02:22:55PM +, Michael Wojcik atmicrofocus.com> wrote: ... |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). #ifdef _MSC_VER maybe, otherwise __extension__ long long int. This definetely worked from pre-Y2K until 2003 with freely available compilers. 'Do not know about __INTEL_COMPILER / icc, iirc came to Linux by then, no? Benchmarked great, and big software needs that help. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
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 +, Michael Wojcik > > wrote: > > > > > > From: openssl-users On > > > > Behalf Of raf via > > > > openssl-users > > > > Sent: Friday, 4 November, 2022 18:54 > > > > > > > > On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via > > > > openssl-users > > > > 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 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
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
On 2022-11-06 23:14, raf via openssl-users wrote: On Sat, Nov 05, 2022 at 02:22:55PM +, Michael Wojcik wrote: From: openssl-users On Behalf Of raf via openssl-users Sent: Friday, 4 November, 2022 18:54 On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users 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 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
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
On Sat, Nov 05, 2022 at 02:22:55PM +, Michael Wojcik wrote: > > From: openssl-users On Behalf Of raf > > via > > openssl-users > > Sent: Friday, 4 November, 2022 18:54 > > > > On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users > > 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 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
RE: an oldie but a goodie .. ISO C90 does not support 'long long'
> From: openssl-users On Behalf Of raf via > openssl-users > Sent: Friday, 4 November, 2022 18:54 > > On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users > 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 and use int64_t and uint64_t. That also requires C99 or later and an implementation which provides those types; they're not required. 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. -- Michael Wojcik
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
On Wed, Nov 02, 2022 at 06:29:45PM +, Michael Wojcik via openssl-users wrote: > > From: openssl-users On Behalf Of Phillip > > Susi > > Sent: Wednesday, 2 November, 2022 11:45 > > > > The only thing to fix is don't put your compiler in strict C90 mode. > > 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. > > But as Tomas wrote, anyone who thinks it is can submit a pull request. > > -- > Michael Wojcik Would this be a choice between backwards-compatibility with C90 compilers and compatibility with 32-bit architectures? Is there another way to get 64-bit integers on 32-bit systems? I suspect that that there are more 32-bit systems than there are C90 compilers. cheers, raf
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
Michael Wojcik via openssl-users writes: > 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. That and there is no substitute for it.
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
Michael Wojcik wrote in : |> From: openssl-users On Behalf \ |> Of Phillip |> Susi |> Sent: Wednesday, 2 November, 2022 11:45 |> |> The only thing to fix is don't put your compiler in strict C90 mode. | |I'm inclined to agree. While there's an argument for backward compatibil\ |ity, 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. Or use __extension__, which definetely worked by then. |But as Tomas wrote, anyone who thinks it is can submit a pull request. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
On 11/2/22 18:29, Michael Wojcik via openssl-users wrote: From: openssl-users On Behalf Of Phillip Susi Sent: Wednesday, 2 November, 2022 11:45 The only thing to fix is don't put your compiler in strict C90 mode. 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. But as Tomas wrote, anyone who thinks it is can submit a pull request. The more that I dig into this and look at the new OpenSSL 3.x the more I am inclined to think C99 is good enough. Everywhere. Also I doubt that the age of the thing matters much. The portability does. Now I await with a flame proof suit for someone to yell "rewrite it all in rust!" Not bloodly likely. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
RE: an oldie but a goodie .. ISO C90 does not support 'long long'
> From: openssl-users On Behalf Of Phillip > Susi > Sent: Wednesday, 2 November, 2022 11:45 > > The only thing to fix is don't put your compiler in strict C90 mode. 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. But as Tomas wrote, anyone who thinks it is can submit a pull request. -- Michael Wojcik
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
Dennis Clarke via openssl-users writes: > On 11/2/22 07:30, Tomas Mraz wrote: >> No, long long and unsigned long long is required and it was required >> for quite some time. The code is mostly C90 but not strictly. >> I suppose on platforms with 64bit long type we could make it work >> without long long though. Pull requests are welcome. >> Tomas Mraz, OpenSSL >> > > So fix it? The only thing to fix is don't put your compiler in strict C90 mode.
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
On 11/2/22 07:30, Tomas Mraz wrote: No, long long and unsigned long long is required and it was required for quite some time. The code is mostly C90 but not strictly. I suppose on platforms with 64bit long type we could make it work without long long though. Pull requests are welcome. Tomas Mraz, OpenSSL So fix it? Feels like we are just going around and around in circles here : Strict C90 CFLAGS results in sha.h:91 ISO C90 does not support long long https://github.com/openssl/openssl/issues/10547 OPENSSL_strnlen SIGSEGV in o_str.c line 76 https://github.com/openssl/openssl/issues/8048 So the code is *mostly* C90 but not really. Got it. Certainly worth looking at. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: an oldie but a goodie .. ISO C90 does not support 'long long'
No, long long and unsigned long long is required and it was required for quite some time. The code is mostly C90 but not strictly. I suppose on platforms with 64bit long type we could make it work without long long though. Pull requests are welcome. Tomas Mraz, OpenSSL On Tue, 2022-11-01 at 22:52 +, Dennis Clarke via openssl-users wrote: > > Good day : > > This always bites me when I try strict C90 : > > In file included from include/openssl/x509.h:41, > from apps/include/apps.h:29, > from apps/lib/app_libctx.c:10: > include/openssl/sha.h:106:37: error: ISO C90 does not support 'long > long' [-Wlong-long] > 106 | # define SHA_LONG64 unsigned long long > | ^~~~ > include/openssl/sha.h:110:5: note: in expansion of macro 'SHA_LONG64' > 110 | SHA_LONG64 h[8]; > | ^~ > include/openssl/sha.h:106:37: error: ISO C90 does not support 'long > long' [-Wlong-long] > 106 | # define SHA_LONG64 unsigned long long > | ^~~~ > include/openssl/sha.h:111:5: note: in expansion of macro 'SHA_LONG64' > 111 | SHA_LONG64 Nl, Nh; > | ^~ > include/openssl/sha.h:106:37: error: ISO C90 does not support 'long > long' [-Wlong-long] > 106 | # define SHA_LONG64 unsigned long long > | ^~~~ > include/openssl/sha.h:113:9: note: in expansion of macro 'SHA_LONG64' > 113 | SHA_LONG64 d[SHA_LBLOCK]; > | ^~ > gmake[1]: *** [Makefile:3989: apps/lib/libapps-lib-app_libctx.o] > Error 1 > gmake[1]: Leaving directory '/opt/bw/build/openssl- > 3.0.7_debian_ppc64.002' > make: *** [Makefile:2958: build_sw] Error 2 > > > etc etc ... > > I can just as neatly go to C11 or some such but I thought the whole > code > base was C90 clean ? At least it was. > > > > -- Tomáš Mráz, OpenSSL
