On 8/21/06 6:58 AM, "Ralf Wildenhues" <ralf.wildenh...@gmx.de> wrote:
> * Ralph H Castain wrote on Mon, Aug 21, 2006 at 02:39:51PM CEST:
>> It sounds, therefore, like we are now C99 compliant and no longer C90
>> compliant at all?
> Well, a compiler supporting C90 plus 'long long' as an extension would
> still be ok. Surely, that's not "strictly C90". But from glancing at
> the mpi.h file in my build tree, some declarations are commented out if
> HAVE_LONG_LONG is not set. Your comments indicate that things still
> would not work with a strict C90 compiler.
True - we removed many of the HAVE_INT64 checks from within the code base
and hardcode int64_t declarations. So if int64_t is not defined and
supported (and I don't believe strict C90 does), we will barf during
Don't think it's a really big deal - just noting that the documentation may
require updating to reflect the new reality.
>> I don't know how big a deal that is, but if true it is something possibly
>> worth noting on our web site and in our release notes. The code will
>> definitely NOT compile unless int64_t is defined and supported.
> I think for Solaris 2.5.1 and Tru64 4.0, you would need a replacement
> definition, but I guess those systems aren't targets for OpenMPI either.
No idea - never heard it discussed, to be honest.
>> PS to Ralf: actually, quite a few systems exist today that do not support
>> long long or int64_t. The majority of computers in the world, in fact, do
>> not do so - they are in embedded systems.
> Right. None of them is fully C99 compliant. AFAIK, some allow (slow!)
> software emulations for long long types.
>> We decided that we were tasked
>> with supporting high-performance computing systems instead, and those are
>> now built almost exclusively from systems that DO support such structures.
>> Just a point of correctness... :-)
> Sure. For practical matters, I would always go for C99 + extensions (as
> in gcc's -std=gnu99; you could use AC_PROG_CC_STDC from Autoconf-2.60
> for some sane choices).
> devel mailing list