fileno() fails on Windows

[a_sn]

fileno()/_fileno()) fails on Windows using the Intel C++ Compiler. I recently just moved my C program compiling from MinGW to ICC, and it's the very only thing that fails. It returns something, then the APIs I send the resulting file descriptor to don't like it, so I can only assume fileno() returns something invalid, even though the numbers it returns are the same as on the MinGW build.

Any known workarounds? I really need to get valid file descriptors.

Here's some example code that fails only on ICC :

[cpp]SNDFILE *load_sndfile(wchar_t *in_path)
{
SF_INFO sfinfo;

FILE * in_file = _wfopen(in_path, L"rb");    // open file, return pointer is valid and fully usable

SNDFILE *sndfile = sf_open_fd (_fileno(in_file), SFM_READ, &sfinfo, 0);    // FAILS HERE. sf_open_fd returns 
// a NULL pointer, only on the ICC build, even though the result of _fileno(in_file) is 4 on both builds

return sndfile;
}[/cpp]

The same thing happens with an entirely different API when calling mpg123_open_fd(mh, _fileno(in_file))

[a_sn]

I just tried replacing _wfopen + _fileno with _wsopen_s(&fd, in_path, _O_BINARY, _SH_DENYNO, _S_IREAD), same outcome.

[Milind_Kulkarni__Int]

What error value do you get from error-reporting functions. Also, please try setting SF_INFO variable to 0 as in :-- memset(&sfinfo, 0, sizeof(sfinfo)); or bzero (...), and then call the failing API, and let me know if it works.

//////////////////////////////////////////

int sf_error (SNDFILE *sndfile) ;

This function returns the current error number for the given SNDFILE. The error number may be one of the following:

enum

{ SF_ERR_NO_ERROR = 0,

SF_ERR_UNRECOGNISED_FORMAT = 1,

SF_ERR_SYSTEM = 2,

SF_ERR_MALFORMED_FILE = 3,

SF_ERR_UNSUPPORTED_ENCODING = 4

} ;

or any one of many other internal error values. Applications should only test the return value against error values defined in as the internal error values are subject to change at any time. For errors not in the above list, the function sf_error_number() can be used to convert it to an error string.

const char* sf_strerror (SNDFILE *sndfile) ;

const char* sf_error_number (int errnum) ;

The error functions sf_strerror() and sf_error_number() convert the library's internal error enumerations into text strings.

int sf_perror (SNDFILE *sndfile) ;

int sf_error_str (SNDFILE *sndfile, char* str, size_t len) ;
///////////////////////////////////////////////////////////////////////

[a_sn]

Thank you Milind.

It returns the error "File contains data in an unknown format."

The puzzling thing is that when doing a read() using fileno(in_file), what's read is correct and identical on all builds. So it seems like it's the two APIs (libsndfile and libmpg123) that somehow mess it up. And of course on the MinGW build the error is "No error."

For libsndfile I just link with the precompiled lib as provided on the site, and for libmpg123 I use late binding at runtime with GetProcAddress() so it only uses the standard DLL file.

[Milind_Kulkarni__Int]

Hi,

Can you post me small test-case by using in this communication. Also, where you downloaded libsndfile precompiled binaries from.
Also, do you mean simply replacing gcc with ICC in MinGW environment results in the error. which versions of gcc & ICC you are using? Are you sure the rest of things all remain same, like what are the steps youare takingto work MinGW with ICC, please list . You may try to workaround, if using -Od (optimization off) works, and gives correct result.
Also, as per your issue, fileno() passes and returns same value, its the libsndfile API that fails?

Please let us know to investigate it better.

[codr]

Hi,

I am currently struggling with the same issue of calling sf_open_fd in Windows outside Mingw. I have tried using VS08 compiler but am planning to try Intel compiler later as well. From what I currently understand (correct me if Im wrong?), Libsndfile is linked in Mingw against msvcrt.dll C runtime whereas MS links against msvcr90.dll C runtime so the file descriptors you get in your code don't exist for the libsndfile precompiled dll. I am not totally sure if this is the case also with Intel compiler.

Visual Studio seems to make it hard to link to the original msvcrt.dll. I have tried to recompile the libsndfile for msvcr90.dll following this: http://www.mingw.org/wiki/SpecsFileHOWTO but still couldn't get it to work. You will also need to embed MS DLL manifest to the dll.

Please inform if you get some progress in this!

[JenniferJ]

I remember seeing discussions about how topass file descriptor between Mingw and msvc dlls, but couldn't find it any more.

This doesn't look like an icl issue. But your note about the different version of vc runtime libs reminds me something.

Try to add /QvcXX option that matches your Mingw libs. If you don't know, just try from newest /Qvc9 to oldest /Qvc7.1.

Jennifer