LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

fgetc reports "argument open stream", fopen() was successful

Solved!
Go to solution

Hello,

 

I'm looking to implement the GNU function "getline()" in CVI and the function starts like:

 

  getline.dll:

  LIBAPI ssize_t WINAPI getline(char **lineptr, size_t *n, FILE *stream) {

    int c;
 

    while (TRUE) {

      c = fgetc(stream);    // Error occurs here

      ...

    }

  }
 

(LIBAPI is DLLEXPORT or DLLIMPORT.) This is then compiled as a DLL and put somewhere global. Then I have another DLL that does this:

 

driver.dll: 

int ReadWaveform(void) { 

 FILE *fwave;

 char *lineptr = NULL;

 int n = 0;

 

 fwave = fopen("waveform.txt", "r");

 len = getline(&lineptr, &n, fwave);

 ... 

 

I get the error "Argument must be an open stream" when the function "fgetc()" is called. If this fgetc() is put into the function ReadWaveform() it doesn't produce an error. The file exists, it's readable (the file permissions are read-only, but read/write doesn't change behaviour either). Both libraries are compiled as debug (or the getline.dll has also been compiled as release, but doesn't change in that the file can't be read and fgetc() reports EOF immediately as it should on error).

 

So there appears to be some cross DLL boundary issues when working with file streams if open the stream in DLL driver.dll and work with it in getline.dll. I haven't had this problem with other C languages.

 

any help on this issue would be appreciated. I'm using CVI 9.0 on WinXP.

 

Thanks,

Jason. 

0 Kudos
Message 1 of 3
(3,819 Views)
Solution
Accepted by topic author jcurl
I think this issue is the same as the malloc/free issue you reported in the other thread. Basically, I think your two DLLs are built with different runtime support options, and so, different CVI runtime engine DLLs are being asked to manage the resources. If you build your DLLs/program with the same runtime support option, then you should be able to share the FILE pointer across modules - you may still not want to do this for other design reasons.
0 Kudos
Message 2 of 3
(3,789 Views)

Yes - the different run time engines is important. They both need to be the same (which for generalisation, therefore need to be the full runtime engine). Then the FILE pointer can be shared. 

0 Kudos
Message 3 of 3
(3,776 Views)