On Thu, Oct 01, 2009 at 12:52:21PM -0700, Sean Hefty wrote:
> >> > @@ -1106,9 +1109,9 @@ void osm_dump_path_record(IN osm_log_t * p_log, IN
> >const ib_path_rec_t * p_pr,
> >> > "\t\t\t\tresv2...................0x%X\n"
> >> > "\t\t\t\tresv3...................0x%X\n",
> >> > cl_ntoh64(p_pr->service_id),
> >> > - inet_ntop(AF_INET6, p_pr->dgid.raw, gid_str,
> >> > + inet_ntop(AF_INET6, (void*)p_pr->dgid.raw,
> >> > gid_str,
> >>
> >> And why is such casting(s) needed?
> >
> >Casting away const like that is incorrect, fix your inet_ntop to have
> >a POSIX signature or ignore the warning.
>
> The WinOF version of inet_ntop is:
>
> const char *inet_ntop(int af, const void *src, char *dst, socklen_t cnt);
>
> The MS version of inet_ntop (available in vista and later) is:
>
> "The ANSI version of this function is inet_ntop"
> PCTSTR WSAAPI InetNtop(
> __in INT Family,
> __in PVOID pAddr,
> __out PTSTR pStringBuf,
> __in size_t StringBufSize
> );
>
> I'm guessing inet_ntop maps directly to InetNtop, but I can't find the
> definition in the header file. We use the MS version of the function when
> available.
Well, if windows header files are providing inet_ntop with the wrong
signature you are kinda stuck, pretty crummy thing for MS to do really.
I've fixed things like this via this approach before:
#include <windows-header.h>
#define inet_ntop my_inet_ntop
static inline const char *my_inet_ntop(int af, const void *src,
char *dst, socklen_t size)
{
return InetNtop(af,(void *)src,dst,size);
}
With #include_next it can be pretty transparent.
Hey, I ran into this the other day:
http://www.gnu.org/software/gnulib/
I wonder if it is something that might help your efforts?
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
