> It looks like the ULL suffix should be safe today; This is misleading statement. *Today* U suffix should be safe, because standard specifies that compiler should pick type automatically depending on value of the constant. In order words suffices beyond U are required only if you need constant to be of wider type, wider than its value, e.g. 13ULL. Well, even then it might be superfluous, because type promotion rules might do it for you. Going back to beginning, to "today U suffix should be safe". Thing is that we kind of live between today and yesterday, making it work not only with contemporary platforms, but even older ones. So real question is if there is compiler supporting 64-bit integer (which is OpenSSL minimum requirement) which would *truncate* constants in question, i.e. with U alone? I'm not aware of any. Next question is if there is compiler that would *fail* to parse ULL? Yes, older Microsoft 32-bit compilers would. Do you see where is it going? It's going toward leaving U alone.
One can wonder if warning is actually justified. I'd argue that this would be a trick question. Compiler in question obviously accepts long long, but it's an *extension* to c89 [which we require and rely on]. Now if compiler already accepts extensions, why would it have to complain about extended constant values? I mean you either process extensions and don't complain, or reject extension and complain. Anyway, the U is here to stay. If warnings sting the eye that much, then the only appropriate action would be to bump standard compliance by passing -std=c9x as additional argument to config/Configure. One can argue that it should be in Configuration/10-main.conf, or be automatically added by ./config. Yes, I suppose it's appropriate assuming that compilers shipped with MacOS X all recognize the option. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4422 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
