Can't open/read txt file in C extension for Python

[Rad226]

Hello everyone,

I'm wrapping some C++ in Python using ctypes.
I have the following problem:
When I'm trying to open/read a txt file by calling a void method in .dll file from Python (no arguments passed from or to python), program fails. Terminal either "hangs" like it's waiting for input or it just passes through without carrying out the open file instructions.

Here is the bare bones example of problematic code
The C++ example.cpp file: (I used python code tags cause there aren't any others to use for code other than Python)

#include <sdtio.h>

extern "C" {
    __declspec(dllexport) void test(){
    File* f_name;
    f_name = fopen("file.txt", "r");     //the "file.txt is in directory"
    //... doesn't goes past this^ line
    }
}

C++ code is compiled by cygwin64 to example.dll

The python ctypes wrapper:

import ctypes

lib = ctypes.CDLL("D:\Code Blocks\C_cwiczenia\stack_over\example.dll")
void_acc = lib.test
void_acc.restype = None
void_acc()
print "program ended !" # this is just so I can see if program executed

As mentioned in C++ code snippet, program doesn't get passed the fopen() line so no "program ended !" shows in Python console.
I tried this with Python 2 and 3 (64bit) on Windows. In both cases issue is thesame.
I belive this has something to do with C++ vs Python streams but I don't know what and I don't know how to get around that.

My question is:
How to open/read text file by calling a funcion in .dll from Python wrapper ?

Any help appreciated.

[Gribouillis]

Did fopen return a non NULL file pointer?

[Rad226]

As far as I know it did not return Null.
When I compile the C++ code into a normal exe it open/reads/prints file no problem.
Issue occurs only when Python code is calling C++ function in dll.

[Gribouillis]

Instead of returning void, you could cast f_name to long and return it to check from python code that a non zero value was returned. This would be a first information about what is really happening. Also, do you fclose() the file later in the code?

[Rad226]

There is nothing to fclose() cause .dll code execution stops immediately on file fopen(). That's the issue cause even if I try to return something to python I don't think it'll pass fopen() point.
To make matters worse, if I try to use any kind of "printing" (fprint(), std::cout<< ) to console from inside dll code, program stops execution like in fopen() case or it throws

Error:
WindowsError: exception: access violation when reading 0x0000000000

(or sometimes 0xFFFFFFFFFFFFF).

[Gribouillis]

I'm allergic to the Windows OS, all I can do is give you a complete example that works for me in Linux.

This is file paillasse/example.cpp (Note that I had to write FILE instead of File)

#include <stdio.h>
 
extern "C" {
    void test(){
        FILE* f_name;
        f_name = fopen("paillasse/test.txt", "r");
        printf("f_name is %p\n", f_name);
        fclose(f_name);
    }
}

Now on the console

Output:
$ g++ --shared -fPIC -o example.so paillasse/example.cpp                                     
$ python3
Python 3.5.2 (default, Apr 16 2020, 17:47:17) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes                                                                            
>>> lib = ctypes.CDLL('./example.so')                                                        
>>> void_acc = lib.test
>>> void_acc.res_type = None                                                                 
>>> void_acc()                                                                               
f_name is 0x226c600
0
>>> 

It is working very well.

[Rad226]

Thank you very much for your help.
I haven't tried it on Linux yet. I'll setup v-box and test it but I'm pretty sure it'll work.
That gave me some clues: it's a Windows problem after all :/
I don't dare to ask you to try to make it work on Windows... however if you have any suggestions on why it's not working under WindowsOS and/or what could I do to try to make it work? I'll be much gratefull. Also I'm curious why Win fails in that matter.
Oh yes, it's "FILE" in original code, I made a mistake here, sorry.

[Rad226]

Yup. Works there (Linux). +1
What is Linux doing differently than Windows that it allows for this to work? -.- I'm puzzled.

[Rad226]

[SOLVED]

It was compiler issue after all.

Instead of cygwin I should've been using mingw-64 bit.
If anyone needs it you can get it from here:
https://www.msys2.org/

With installation I followed instructions in this yt video:
https://www.youtube.com/watch?v=aXF4A5UeSeM

Now it works fine.