Not everything that ‘valgrind’ reports is actually an error. In each case, you
need to look at the code to see if there’s really an error there.
> For example I found this code inside GroupsockHelper.cpp:
>
>
> static Boolean getSourcePort0(int socket, portNumBits& resultPortNum/*host
> order*/) {
> sockaddr_storage testAddr;
> setPortNum(testAddr, 0);
>
> SOCKLEN_T len = sizeof testAddr;
> if (getsockname(socket, (struct sockaddr*)&testAddr, &len) < 0) return
> False;
>
> resultPortNum = ntohs(portNum(testAddr));
> return True;
> }
I’m not really sure if there’s anything really wrong here. “getsockname()”
fills in (i.e., returns) the value of “testAddr”; it doesn’t read it. And the
subsequent call to “portNum(testAddr)” shouldn't read an uninitialized value,
because the port number should have been filled in by the earlier (successful)
call to "getsockname()”.
What is, perhaps, strange, is the call to “setPortNum()”, which probably isn’t
really needed. And the implementation of “setPortNum()” does, indeed, rely
upon the “ss_family” field, which, in this case, will be uninitialized. So
perhaps that’s what upset ‘valgrind’ here?? So I’ve gone ahead and installed a
new version (2021.08.17) of the LIVE555 code that changes the implementation of
"setPortNum()” to not rely upon “ss_family”. This might make ‘valgrind’
happier in this case.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
