I'm in favor of following the evolution of C compilers to C99, but only if we can ensure that C99 features are ubiquitous - we should not assume this is the case. I am particularly worried about the "most compilers today support it" - before making this change, we should undertake a real survey of systems, and that must include non-GNU systems and compilers, and it must include compilers in service, not just the current generation of compilers (we've often had users with compilers that were several years old). Among the list of compilers that we should include are those from the Portland Group, Intel, HP, IBM, Sun, Cray, NEC, Fujitsu, and Hitachi. And I'm sure I've forgotten a few. Bill On Oct 24, 2009, at 12:59 PM, Pavan Balaji wrote:
For as long as MPICH/MPICH2 has been developed, we have always tried to maintain the code as C89 compatible as possible. This is, in general, a good idea. However, this required us to add a lot of code to work with platforms and compilers that don't have C99 support. Given that C99 is almost a decade old now, and most compilers today support it, I'd like to initiate a discussion to see what people's thoughts are on requiring "C89++" support from the compiler for MPICH2.
By C89++, I mean C89 together with a few features from C99. My initial list contains just two features with some reasoning:
1. snprintf -- this will allow us to totally get rid of MPIU_Snprintf given that it is not complete anyway, but only provides a handful of options.
2. __VA_ARGS__ -- this will allow us to remove the requirement to add FUNCNAME for each function we add and a lot of code that checks if VA_ARGS is defined before doing anything with it.
If there are other C99 features that would be useful, please point them out as well. It goes without saying that the configure will of course still check if these exist. However, if they are not found, instead of trying to fall back to some other internal implementation, it'll abort.
If you are against this approach, it'll be helpful if you can point out systems/compilers where it might be a problem.
If you support this change, please do point that out as well.
Thanks,
-- Pavan
-- Pavan Balaji http://www.mcs.anl.gov/~balaji
William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign