Sounds reasonable. I thanks for explaining. Ethan
On Fri, May 13, 2011 at 14:34, Ben Pfaff <[email protected]> wrote: > On Fri, May 13, 2011 at 02:14:33PM -0700, Ethan Jackson wrote: >> > + ? ?if (!getaddr(fd, (struct sockaddr *) &ss, &len)) { >> > + ? ? ? ?if (ss.ss_family == AF_INET) { >> > + ? ? ? ? ? ?struct sockaddr_in sin; >> > + >> > + ? ? ? ? ? ?memcpy(&sin, &ss, sizeof sin); >> > + ? ? ? ? ? ?ds_put_format(string, IP_FMT":%"PRIu16, >> > + ? ? ? ? ? ? ? ? ? ? ? ? ?IP_ARGS(&sin.sin_addr.s_addr), >> > ntohs(sin.sin_port)); >> >> I be misunderstanding some basic principle of C here, but why do you >> need to memcpy? Can't you simply do struct sockaddr_in *sin = (struct >> sockaddr_in *)&ss ? > > In practice, probably you could. > > In theory, this might violate C's aliasing rules, which (in outline) > say that an object declared of one that may only be accessed either as > that type (or a compatible type) or as a character type. GCC these > days warns about potential or actual violations, so I prefer to avoid > them. > > memcpy() always (conceptually) accesses its arguments as arrays of > character type. > > In practice again, glibc defines sockaddr and friends as a weird GCC > extension that avoids aliasing violations and warnings for them. But > other OSes don't necessarily do that. > > In summary, it's easier to memcpy() on slow paths where it doesn't > matter anyway. Makes life easier, in my opinion. > _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
