I am porting an application from 32 bit to 64 bit. The application includes gSoap generated ANSI C source code. The prototypes of several generated soap functions include int
data types in the argument list, such as:
int PASCAL FAR setsockopt (
__in SOCKET s,
__in int level,
__in int optname,
__in_bcount_opt(optlen) const char FAR * optval,
__in int optlen);
But, when called in stdsoap2.c, the 5th argument in this example is passed the sizeof
macro:
if (setsockopt(fd, SOL_SOCKET, SO_LINGER, (char*)&linger, sizeof(struct linger)))
{ ...
}
The sizeof
macro returns a value of the size_t
type which is just an unsigned int
. When compiling in the 32 bit environment, this presented no problem, however, when compiling in the 64 bit environment, the warning: "Conversion from unsigned __int64
to int
might lose data".
I understand the data loss problem. My question is where and how should it be placed in the code to address the problem short of (int)
type casting for each sizeof
macro being passed as an int
within stdsoap2.c
(there are 32 warnings in stdsoap.c
alone). I would like to avoid editing an automatically generated source file if possible.
For those familiar with gsoap
methods, I have included the following:
#ifdef WITH_SOAPDEFS_H
# include "soapdefs.h" /* include user-defined stuff */
#endif
and am using soapdefs.h
in my project. This file has project wide scope, perhaps this file would be a good place for addressing the problem, then the question would just be how?
size_t
isn't "just an unsigned int
"; as the warning shows, on a 64-bit platform it's commonly larger than that.
Where you should do the check depends on the application, but if you're passing the value of a sizeof
expression, you could replace that with an appropriately defined constant:
enum {
SIZEOF_LINGER = sizeof(struct linger);
};
The compiler will issue a warning if the constant is too large to be converted, so if you compile with (the equivalent of GCC's) -Wall -Werror
, you're safe.