[mpich-discuss] Fortran/C string passing convention
Dave Goodell
goodell at mcs.anl.gov
Mon Feb 4 08:34:50 CST 2013
Hi Nils,
It looks like Bill is tracking this issue in http://trac.mpich.org/projects/mpich/ticket/1790, in case you want to follow along at home.
-Dave
On Feb 1, 2013, at 1:44 PM CST, William Gropp wrote:
> Thanks - when this code was written, all of the Fortran compilers used ints, but that was a long time ago. I'll look into both a robust configure check and updating the code.
>
> Bill
>
> William Gropp
> Director, Parallel Computing Institute
> Deputy Director for Research
> Institute for Advanced Computing Applications and Technologies
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
>
>
>
> On Feb 1, 2013, at 9:20 AM, Nils Smeds wrote:
>
>> Hi all,
>>
>> I notice in the mpich source code that Fortran string length arguments are supposed to be int. However, in many compilers this hidden argument is size_t. Below are excerpts from documentation of Intel ifort, GFortran and PathScale. (The last one claims to use int as the string length). In practice using an int here "just works" - at least for strings shorter than 2GB. Since the string length argument is passed by value there is little risk for any errors to occur as it is most likely to be passed in a register so any "additional upper bits" get cleared in the process of the call. Possibly it could be a problem with routines with vary many arguments where arguments are passed over the stack.
>>
>> ./src/mpi/romio/adio/include/adio.h
>> ./src/binding/f77/mpi_fortimpl.h
>>
>> #ifdef USE_FORT_MIXED_STR_LEN
>> #define FORT_MIXED_LEN_DECL , int
>> #define FORT_END_LEN_DECL
>> #define FORT_MIXED_LEN(a) , int a
>> #define FORT_END_LEN(a)
>> #else
>> #define FORT_MIXED_LEN_DECL
>> #define FORT_END_LEN_DECL , int
>> #define FORT_MIXED_LEN(a)
>> #define FORT_END_LEN(a) , int a
>> #endif
>>
>>
>> Intel Fortran
>>
>> http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/fortran-win/index.htm
>> (Not a perfect example, but the best I could find) I've seen more explicit formulations in earlier Intel manuals.
>>
>> http://software.intel.com/en-us/forums/topic/270023
>> Is more to the point
>>
>> GFortran
>>
>> http://www.xgear.eu/callfortranfromc.html
>>
>> Fortran functions that receive string variables from C
>> C
>> This is slightly more complicated. The Fortran function must be declared at the beginning of the C calling function (e.g. main) like this:
>> extern void load_(char *string, size_t *len_string);
>>
>> Note that we have to pass all variables to Fortran as pointers. Our string variable is already a pointer, but we have to pass the string's length as a pointer too. Although the function name is not case sensitive in Fortran, it gains an underscore in the C declaration and when it is called:
>> len_string = strlen(string);
>>
>> load_(string, &len_string);
>> Note that in passing the string from C to Fortran we also need to pass the length of the string, hence the use of strlen beforehand (not forgetting to declare the string length variable as a size_trather than an int).
>>
>> [ NOTE: The above is likely incorrect in that I believe the declaration should be size_t len_string and the call load_(string, len_string).
>> The actual arguments are passed by reference but the hidden length arguments are likely passed by value.
>> (My comment)
>> ]
>>
>>
>> Pathscale
>>
>> http://www.pathscale.com/EKOPath-User-Guide#htoc66
>>
>> Like most Fortran compilers, we represent character strings passed to subprograms with a character pointer, and add an integer length parameter to the end of the call list.
>> _______________________________________________
>> discuss mailing list discuss at mpich.org
>> To manage subscription options or unsubscribe:
>> https://lists.mpich.org/mailman/listinfo/discuss
>
> _______________________________________________
> discuss mailing list discuss at mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/discuss/attachments/20130204/05f30388/attachment.html>
More information about the discuss
mailing list