- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Compiling with Intel Visual Fortran Compiler XE 12.0.0.104 [IA-32]...
ExternalInterface.f90
D:\\EPPgm\\DBL_Source\\ExternalInterface.f90(303): error #8532: A character dummy argument with length other than 1 is not interoperable. [FILENAME]
The code is:
INTERFACE
INTEGER(C_INT) FUNCTION establishclientsocket(fileName) BIND (C, NAME="establishclientsocket")
! Returns the logical unit number of the socket
USE ISO_C_BINDING, ONLY: C_INT, C_CHAR
CHARACTER(kind=C_CHAR, len=*) :: fileName ! file from which socket port number will be read
END FUNCTION establishclientsocket
END INTERFACE
Is this an error on the V12 compiler or something we need to find a work around for? (or a rewrite of the interface code -- which is really part of a different system)?
Linda
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The only character types that are C-interoperable are of length 1, according to the Fortran standard. This rule is enforced not only by IFort 12, but also by IFort 11.1, and by other compilers such as GFortran.
You can, however, change
and let the rules of sequence association work for you.
You can, however, change
[fortran]CHARACTER(kind=C_CHAR, len=*) :: fileNameto
[/fortran]
[bash]CHARACTER(kind=C_CHAR), dimension(*) :: fileName
[/bash]
and let the rules of sequence association work for you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, will give that a try.
Linda
Linda
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This did work for me (compiles at least -- others will have to test) but I don't understand why this was an ERROR with the compiler rather than a warning?
I don't have "standards checking" turned on and certainly don't have standards warnings as errors turned on.
Linda
I don't have "standards checking" turned on and certainly don't have standards warnings as errors turned on.
Linda
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You wrote: "I don't understand why this was an ERROR with the compiler rather than a warning".
Speaking as a user of ISO_C_BINDING, I think that I should expect ERROR rather than WARNING. Had we been discussing interoperability of C and Fortran-77, a situation in which the programmer had the entire responsibility of making the C and Fortran interoperate, WARNING (more usually, not even a warning could be expected) would have been appropriate. The Fortran compiler did not know anything about C, and vice-versa.
ISO_C_BINDING can be thought of as a set of voluntarily adopted set of rules. You follow the rules, and the Fortran compiler takes care of making your code work properly with objects produced by the approved C-compiler. Therefore, ERROR is appropriate when the Fortran compiler can detect code that does not conform to the rules. Using WARNING instead would be somewhat like brushing dirt under the carpet. With code that is in violation, especially with CHARACTER(len=) arguments, runtime errors are almost guaranteed.
Speaking as a user of ISO_C_BINDING, I think that I should expect ERROR rather than WARNING. Had we been discussing interoperability of C and Fortran-77, a situation in which the programmer had the entire responsibility of making the C and Fortran interoperate, WARNING (more usually, not even a warning could be expected) would have been appropriate. The Fortran compiler did not know anything about C, and vice-versa.
ISO_C_BINDING can be thought of as a set of voluntarily adopted set of rules. You follow the rules, and the Fortran compiler takes care of making your code work properly with objects produced by the approved C-compiler. Therefore, ERROR is appropriate when the Fortran compiler can detect code that does not conform to the rules. Using WARNING instead would be somewhat like brushing dirt under the carpet. With code that is in violation, especially with CHARACTER(len=
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's fine -- why wasn't it flagged at all in earlier (V11.1) versions of the compiler?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Various possibilities (I don't know the specific reason). Maybe someone pointed out that the compiler is required to diagnose violations of the standard, at least when appropriate options are set. This would not be the first time that requirement is met by turning the non-conforming code into an error. Leaving an inadvertent extension in place would require assurance that it doesn't permit undiagnosed failure, as well as making it whine when -stand is set.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are always improving the diagnnostic capabilities of the compiler. This was a case we did not detect before.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting Steve Lionel (Intel)
We are always improving the diagnnostic capabilities of the compiler. This was a case we did not detect before.
And this is very much appreciated here, for all the usual reasons. Theeffort Intel has invested and continues to devote to both ensuring and documenting compliance with published standardsa key consideration in our adoption and continued use ofIVF.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page