IFC Vs CVF for argument passing

[tonyjay68]

When I try to run (my first)CVF converted to IFC project, It fails at run time as arguments are passed from C to fortran (an access violation when trying to use the passed variable as the pointer to the variable is not valid)

I use the same prototyping across all our builds (Unix and windows)and this has not been a problem up to now. Perhaps I'm doing something a bit illegal which IFC is picking up, but the other platforms arn't ?

I have attached a trivial example, run and compile in debug on IFC 8.

i.e.

I have afortranroutine

SUBROUTINE VERSION (
$ Program, Module,
$ String, Number,
$ iEr
$ )
C
C*p* Passed Variables
C
INTEGER iEr
CHARACTER*(*) Program, Module, String
REAL Number

and the calling C routine uses the prototype

extern "C"
void __stdcall VERSION(const char *, const char * , char *, float*, int*, int,int,int);

and the call is

void versionftoc(const char * program, const char * module, char * input)
{
char CharVersion[40]=" ";
float FloatVersion=0;
int ier=0;
int i=0;

VERSION(program, module, CharVersion, &FloatVersion, &ier,
strlen(program),
strlen(module),
sizeof(CharVersion)
);

The intel project shows that I have "CVF" for argument passing (no idea what this means !) an I use , of course pass string length after all args.

Any comments ?

Tony

[Steven_L_Intel1]

There's a bug where /iface:nomixed_str_len_arg is overridden by /iface:cvf. The latter is intended to apply CVF defaults, and you get this when you convert a project from CVF.

The workaround is to change the calling convention to default and remove the __stdcall from the C declarations of cprog and VERSION. I'll report this to engineering.

[tonyjay68]

Steve

Thanks for the info. This issue was one where I could not work out whether I was doing the wrong thing !

Fortunately my __stdcall is actually a #define STDCALL __stdcall, so I should be able to recompile by changing one header and all the project options

Tony