[Live-devel] (no subject)
Ross Finlayson
finlayson at live555.com
Thu Nov 30 07:45:39 PST 2023
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/
More information about the live-devel
mailing list