I think ‘valgrind’ is mistaken/confused here, because “sockaddr_storage” is a
structure whose contents depend on the address type being stored. E.g., on my
FreeBSD system, it’s defined as follows:
#define _SS_MAXSIZE 128U
#define _SS_ALIGNSIZE (sizeof(__int64_t))
#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof(unsigned char) - \
sizeof(sa_family_t))
#define _SS_PAD2SIZE (_SS_MAXSIZE - sizeof(unsigned char) - \
sizeof(sa_family_t) - _SS_PAD1SIZE - _SS_ALIGNSIZE)
struct sockaddr_storage {
unsigned char ss_len; /* address length */
sa_family_t ss_family; /* address family */
char __ss_pad1[_SS_PAD1SIZE];
__int64_t __ss_align; /* force desired struct alignment */
char __ss_pad2[_SS_PAD2SIZE];
};
I.e., not all bytes in this structure will be used - and that’s OK, as long as
no part of the structure is ever read without having been previously written
to. And that should be the case in our code; in particular, in
"MultiFramedRTPSource::networkReadHandler1()”, “fromAddress” should never be
accessed without first having been assigned[*] - even though some *bytes*
within the “fromAddress” structure might not actually have been written to.
I’m not a great fan of ‘valgrind’, because people often use it
indiscriminately, and post - to this mailing list - what they think are ‘bugs’,
without really understanding the true nature of the bug, or if it really is
actually a bug.
[*]If parts of our code really do depend upon uninitialized values, then that
really would be a bug, and I’ll fix it. But I’m not going to paper over this
my making a change just to keep ‘valgrind’ quiet.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
