I built a multi-language software image processing program and made it generally available with binaries for Mac OS X and Ubuntu. The binaries have been tested on their respective operating systems and every thing works perfectly. I recently also tried to release binaries for Windows (64 bit) but the GCC (through MinGW-w64) compiler gave me warnings for one of the C programs when I create the shared library (dll) file. This did not happen in Mac OS X or Ubuntu. Here are the warnings and the corresponding line of code in the C file:
warning: passing argument 3 of '_beginthreadex' from incompatible pointer type [enabled by default]
Line 464:
ThreadList[i] = (HANDLE)_beginthreadex( NULL, 0, &ThreadFunc, &ThreadArgs[i] , 0, NULL );
The second and stranger warning:
c:\mingw\x86_64-w64-mingw32\include\process.h:31:29: note:
expected 'unsigned int <*><void *>' but argument is of type 'void * <*><void *>'
_CRTIMP uintptr_t _cdecl _beginthreadex<void *_Security,unsigned _Stacksize,unsigned <_stdcall *_StartAddress> <void *>,void *_ArgList,unsigned _InitFlag,unsigned *_ThrdAddr >;
Line 34:
#include <process.h>
This belongs in this larger code block:
/* Multithreading stuff*/
#ifdef _WIN32
#include <windows.h>
#include <process.h>
#else
#include <pthread.h>
#endif
#include <stdbool.h>
The problem seems to emanate from #include <process.h> since for Mac OS X and Ubuntu #include <pthread.h> is used. Any help figuring this out? The full C program is here .
The messages when compiling for windows but not for other systems are hardly surprising. The offending code will only be seen by the compiler when building for windows, due to usage of the _WIN32 macro which is only defined by the compiler when code is built for windows.
The "second and stranger warning" is describing the cause. The third argument of the (windows specific) _beginthreadex() function is specified to be a pointer to a function that returns an unsigned int. The actual ThreadFunc being passed is a function that returns a void *.
The fix to make the code acceptable to a windows compiler is to change the return type of ThreadFunc() to return unsigned int. That will break the code for other systems, so you need to do the changes conditionally (i.e. have two versions of the function, and select the right one by testing the _WIN32 macro).
#ifdef _WIN32
/* use the windows version of the function here */
#else
/* use the non-windows version of the function here */
#endif
Related
Information:
LabVIEW: 2019
Version: 19.0.1 (32-bit)
Operating system: Windows 64-bit
Labview crashes completely after an indefinite time. I call three functions of the C-DLL. I loop through all the functions of the DLL over and over again. After about 2 minutes to an hour Labview crashes without reason.
Calling of OpenConnection():
Calling of QueryOpenConnectionStatus():
Calling of CloseConnection():
Type definition of TConnectionResult
Follow the given Headerfile.h
#ifndef __epMCOMLib_h_
#define __epMCOMLib_h_
#include <stdint.h>
#include <stddef.h>
#define DLLIMPORT __declspec(dllimport)
#pragma pack (push,1)
typedef struct {
uint16_t DLLFailureCode;
uint8_t ConnectionStatus;
uint32_t SystemFailureCode;
} TConnectionResult;
#pragma pack (pop)
#ifdef __cplusplus
extern "C" {
#endif
DLLIMPORT uint16_t __cdecl OpenConnection(uint8_t PortType,
char * PortName,
uint32_t OnConnectSucces,
uint32_t * Handle);
DLLIMPORT void __cdecl QueryOpenConnectionStatus(uint32_t Handle,
TConnectionResult * Result);
DLLIMPORT uint16_t __cdecl CloseConnection(uint32_t Handle);
#ifdef __cplusplus
} // extern "C"
#endif
#endif //#ifndef __epMCOMLib_h_
The DLL works perfectly. For this I integrated the DLL in Python ,LabWindows/CVI, C++ and Delphi. There is no crash in these programming languages!
Can anyone give me any useful tips on how to further isolate or eliminate the error.
Even if a function of the DLL has been executed and the DLL is then closed, it still causes a crash. As if it's still in memory. It feels like looking for a needle in a haystack.
Run the thread on the UI thread instead of any thread!
In the log file of the DLL I could see that the thread is attached and detached. I suspect this is causing a memory violation. Since Labview is shot down by its called DLL.
In my experience, sometimes DLL called with LabVIEW causes this kind of problems and with no specific reasons and solutions (even for the NI technical support).
Try to launch your LabVIEW applicatin with Administrator privilegies. In some cases, this solves the problem.
I'm trying to port some code from windows to linux, but I'm having difficulty with support for large files. off_t seems to be defined when gcc is run with -std=c89 but not for -std=c99. Even a trivial test case will not compile:
#define _LARGEFILE_SOURCE
#define _LARGEFILE64_SOURCE
#define _FILE_OFFSET_BITS 64
#include <stdio.h>
int main()
{
off_t x = 0;
return 0;
}
It really doesn't seem like this should be difficult (in fact, it's not on all other operating systems). Anyone have any idea what is happening?
The type off_t is not defined by ISO C; it's defined by POSIX.
I get
error: unknown type name ‘off_t’
if I compile with either -std=c90, -std=c99, or -std=c11. That's to be expected, since those options specify conformance to the relevant C standard. Since you're compiling C code that doesn't conform to any of those C standards, you shouldn't use those options.
I find that off_t is defined if I compile with -std=gnu90, -std=gnu99, or -std=gnu11.
Also, off_t is the return type of the lseek function, whose man page on my system says it requires:
#include <sys/types.h>
#include <unistd.h>
You should add those.
I am learning C.
In this program
I use sleep function to slowdown a count down.
My text book doesn't specify a library I should include to use the sleep function.
So I use it without including any special library for it and it works.
But it gives me this warning message in codeblocks.
I tried to include <windows.h> but still the same warning message appears.
warning D:\Project\C language\trial8\trial8.c|19|warning: implicit
declaration of function `sleep'|
And here is my code.
#include <stdio.h>
int main()
{
int start;
do
{
printf("Please enter the number to start\n");
printf("the countdown (1 to 100):");
scanf("%d",&start);
}
while(start<1 || start>100);
do
{
printf("T-minus %d\n",start);
start--;
sleep(3000);
}
while(start>0);
printf("Zero!\n Go!\n");
return(0);
}
I want to know what does the warning message mean? How important is it? Is there anything that I should do about it? Note that the program works anyway.
The issue is in the libraries (header files):
on Windows:
#include <windows.h> and Sleep(1000); => 1000 milliseconds
on Linux:
#include <unistd.h> and sleep(1); => 1 second
The function sleep is not part of C programming language. So, C compiler needs a declaration/prototype of it so that it can get to know about about number of arguments and their data types and return data type of the function. When it doesn't find it, it creates an Implicit Declaration of that function.
In Linux, sleep has a prototype in <unistd.h> and in windows, there is another function Sleep which has a prototype in <windows.h> or <synchapi.h>.
You can always get away with including header, if you explicitly supply the prototype of the function before using it. It is useful when you need only few functions from a header file.
The prototype of Sleep function in C on windows is:
VOID WINAPI Sleep(_In_ DWORD dwMilliseconds);
Remember, it is always a good practice to supply the prototype of the function being used either by including the appropriate header file or by explicitly writing it. Even, if you don't supply it, compiler will just throw a warning most of the time and it will make an assumption which in most cases will be something that you don't want. It is better to include the header file as API might change in future versions of the Library.
Windows doesn't have the sleep function. Instead, it has Sleep, which takes the number of milliseconds to sleep:
VOID WINAPI Sleep(
_In_ DWORD dwMilliseconds
);
You'll need to either #include <windows.h> or #include <synchapi.h>, depending on the version of Windows you're running. See MSDN for more details.
Update in 2022:
As it is stated on the Linux man page here we need to include unistd.h and should do fine for all OS.
#include <stdio.h>
#include <unistd.h>
int main()
{
sleep(1); /* sleep for 1 second*/
printf("END\n");
return 0;
}
To make it more cross-platform, try this:
#ifdef _WIN32
#include <Windows.h>
#else
#include <unistd.h>
#endif
I have written a multithread server program in C, which echoes back all the data that a client sends.
Initially, I used poll() function in my program to detect POLLRDHUP event, for that I defined _GNU_SOURCE macro (This event is defined here).
Later I updated my code & removed poll() function, however I forgot to remove _GNU_SOURCE macro.
Now my code is finally complete (and a little long to post, more than 250 lines). Before removing macro I was compiling my program using:
gcc multi_thread_socket_v4.c -Wall -Werror -g -lpthread -o multi_thread_socket
and it worked fine: No errors, no warnings
After I removed the macro definition, and compiled using same command-line, the output of gcc was:
multi_thread_socket_v4.c: In function ‘main’:
multi_thread_socket_v4.c:194: warning: implicit declaration of function ‘pthread_mutexattr_settype’
multi_thread_socket_v4.c:194: error: ‘PTHREAD_MUTEX_ERRORCHECK’ undeclared (first use in this function)
multi_thread_socket_v4.c:194: error: (Each undeclared identifier is reported only once
multi_thread_socket_v4.c:194: error: for each function it appears in.)
I have included all the required libraries as it worked fine initially.
I peeked into pthread.h at /usr/include/pthread.h and found out this:
/* Mutex types. */
enum
{
PTHREAD_MUTEX_TIMED_NP,
PTHREAD_MUTEX_RECURSIVE_NP,
PTHREAD_MUTEX_ERRORCHECK_NP,
PTHREAD_MUTEX_ADAPTIVE_NP
#ifdef __USE_UNIX98
,
PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
PTHREAD_MUTEX_ERRORCHECK = PTHREAD_MUTEX_ERRORCHECK_NP,
PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL
#endif
#ifdef __USE_GNU
/* For compatibility. */
, PTHREAD_MUTEX_FAST_NP = PTHREAD_MUTEX_TIMED_NP
#endif
};
and this:
#ifdef __USE_UNIX98
/* Return in *KIND the mutex kind attribute in *ATTR. */
extern int pthread_mutexattr_gettype (__const pthread_mutexattr_t *__restrict
__attr, int *__restrict __kind)
__THROW __nonnull ((1, 2));
/* Set the mutex kind attribute in *ATTR to KIND (either PTHREAD_MUTEX_NORMAL,
PTHREAD_MUTEX_RECURSIVE, PTHREAD_MUTEX_ERRORCHECK, or
PTHREAD_MUTEX_DEFAULT). */
extern int pthread_mutexattr_settype (pthread_mutexattr_t *__attr, int __kind)
__THROW __nonnull ((1));
I checked out here to check if __USE_UNIX98 is a feature test macro, but it was not there.
So please help me understanding the reasons for the error, because the function & the macro where gcc shows error are defined in POSIX standard. I do not know what more info regarding my problem will be required so please tell me, I will update my question.
You should use
#define _POSIX_C_SOURCE 200112L
if you want to use POSIX features such as pthread_mutexattr_settype ... see http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html
Another possibility is
#define _XOPEN_SOURCE 700
See http://man7.org/linux/man-pages/man7/feature_test_macros.7.html and http://pubs.opengroup.org/onlinepubs/9699919799/
Setting _GNU_SOURCE includes POSIX and lots of other definitions.
P.S. I would expect that including <pthread.h> includes <features.h>, which by default defines _POSIX_C_SOURCE as 200112L, but it's possible that you have defined something that overrides that ... see /usr/include/features.h on your system for details of the symbols and their usage.
It doesn't, your problem likely lies elsewhere.
I just compiled a trivial program with the following content:
#include <pthread.h>
int main(int argc, char **argv)
{
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_ERRORCHECK);
return 0;
}
This compiles perfectly with gcc -pthread -Wall -Werror a.c.
It's possible that another part of your program causes this, by eg. doing something silly like defining _PTHREAD_H, or some other minor sabotage.
You might want to try to get a minimal test case by using a tool like delta or creduce, which will probably make the problem evident.
When you're using old libraries (e.g. 2.1.x) you should use
#define __USE_UNIX98
Using a macro beginning with "__" it's not usually a good idea, but sometimes it's the only way... see also this discussion
I have a C program that uses getaddrinfo(). It works as expected on Linux and Mac OS X.
I'm in the middle of porting it to Windows.
When I compile it (with MinGW gcc) I get the following warnings:
ext/socket/socket.c: In function 'sl_tcp_socket_init':
ext/socket/socket.c:98:5: warning implicit declaration of function 'getaddrinfo' [-Wimplicit-function-declaration]
ext/socket/socket.c:104:9: warning implicit declaration of function 'freeaddrinfo' [-Wimplicit-function-declaration]
Then the entire thing fails to link with undefined references to getaddrinfo() and freeaddrinfo().
Now, according to this MSDN page, getaddrinfo() is supported on Windows and is located in the header file Ws2tcpip.h and the library file Ws2_32.lib.
I'm including Ws2tcpip.h and linking with -lWs2_32, so I'm not sure why this isn't working.
If you have a look at line 297 of ws2tcpip.h, you can see that there's a check of the value of _WIN32_WINNT.
#if (_WIN32_WINNT >= 0x0501)
void WSAAPI freeaddrinfo (struct addrinfo*);
int WSAAPI getaddrinfo (const char*,const char*,const struct addrinfo*,
struct addrinfo**);
int WSAAPI getnameinfo(const struct sockaddr*,socklen_t,char*,DWORD,
char*,DWORD,int);
#else
/* FIXME: Need WS protocol-independent API helpers. */
#endif
Just #define _WIN32_WINNT before your includes.
If you want to make your code compiler-wide you should actually also define NTDDI_VERSION with the same OS version as _WIN32_WINNT. Without that defining only _WIN32_WINNT will not let you to use getaddrinfo() with some compilers (i.e. Watcom). It is better to wrap it in the same way as Windows SDK does:
#define _NTDDI_VERSION_FROM_WIN32_WINNT2(ver) ver##0000
#define _NTDDI_VERSION_FROM_WIN32_WINNT(ver) _NTDDI_VERSION_FROM_WIN32_WINNT2(ver)
#ifndef _WIN32_WINNT
# define _WIN32_WINNT 0x501
#endif
#ifndef NTDDI_VERSION
# define NTDDI_VERSION _NTDDI_VERSION_FROM_WIN32_WINNT(_WIN32_WINNT)
#endif
Supposedly the proper way to fix this is:
#define WINVER WindowsXP
Or perhaps more sensibly adding -DWINVER=WindowsXP to your CPPFLAGS.
Ref: http://mingw.5.n7.nabble.com/Undefined-reference-to-getaddrinfo-td5694.html
Note: didn’t work for me however.