This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
* 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.
> 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.
> 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).