On 05/11/2018 15:56, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of lu zhihong Sent: Thursday, November 01, 2018 05:58when complie openssl 1.1.1 on linux 32bit platform, i met some compile warning,like: crypto/ec/curve448/curve448_tables.c:415: integer constant is too large for 'long' type the 64bit constant is default to 32bit long type, how should i deal with these warning?See https://github.com/openssl/openssl/issues/7556. Here's my initial take, though it's based only on a quick discussion with the developer here who raised that issue. I haven't tried modifying the OpenSSL sources yet. The warnings are caused by hexadecimal constants (0x...) that are larger than 32 bits. C99 and later requires that the implementation use the smallest suitable type for a hex integer constant, up to and including unsigned long long. See ISO 9899-1999 6.4.4.1 #5. (This is also true for octal constants, but not decimal ones. I haven't looked in the Rationale to see if the committee explained this decision.) C89/C90 and C94 don't have the "long long" types. Consequently, when compiling the OpenSSL 1.1.1 sources using an implementation that's running in a C90 or C94 mode, and is using an IL32 integer representation, the compiler is quite right to complain about those constants. (Of course, the standard lets an implementation issue any diagnostic for any reason whatsoever, but well-behaved C99 implementations shouldn't complain about those constants.) I think two fixes are required: 1. All platform configurations should specify a C99-conforming, or C99-plus-extensions, or later version of C, mode where available. In the issue report Simon mentions that the AIX configuration using IBM's xlC (or C Set or whatever IBM is calling it this week) is not using C99 mode, for example. That is a Bad Thing. When xlC is invoked as "cc" and no -qlanglvl option is used, it defaults to the C89-plus-extensions mode from the IBM RT PC. The OpenSSL configure script should be using CC=xlc or adding the appropriate -qlanglvl option for this platform. With GCC on Linux (or anywhere else) there's probably some option to enable C99-plus-extensions and have those integer constants interpreted as unsigned long long even in 32-bit builds. I don't blame the OpenSSL maintainers here - users (this includes me) should be submitting better configurations for the platforms we use. When we (here at the division of Micro Focus which Simon and I work in) finish our OpenSSL 1.1.1 testing, we plan to experiment with various updates like this and submit issues and pull requests. 2. The constants in question should have the "ULL" suffix, indicating they're expected to be interpreted as unsigned long long. Since "ULL" was not defined prior to C99, this should cause compilation of the affected sources to fail when the implementation doesn't support unsigned long long. That's better than a bunch of warnings which many people are likely to ignore. If there are platforms which support 64-bit integer constants but not the "ULL" suffix, we could hide this behind a token-pasting macro. But as I wrote above, I haven't tested those yet.
Note that requiring C99 would break compatibility with older platforms such as CE 5.x, so that is not a viable option. Lots of pre-C99 compilers do have either the "unsigned long long" or "unsigned __int64" type (or both) with corresponding constant suffixes of ull and ui64. Other pre-C99 compilers make "unsigned long" (ul) 64 bit. However I would doubt the sanity of a compiler warning about array initialization constants that are in range for the array member type, even if they are not in range for some other expression type. Thus for constants used in array initialization, it may be better to use compiler specific command line options for each picky compiler. For other compilers maybe there is a common OpenSSL internal macro that appends ull or ui64 or ul as appropriate to the compiler+arch target (we use such a macro for in-house code). 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
