> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of lu zhihong > Sent: Thursday, November 01, 2018 05:58 > > when 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. -- Michael Wojcik Distinguished Engineer, Micro Focus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
