Re: kern/51450 (tcptraceroute stopped working properly in 6.0 -> 7.0 transition)

[Havard Eidnes <he%NetBSD.org@localhost>]

The following reply was made to PR kern/51450; it has been noted by GNATS.

From: Havard Eidnes <he%NetBSD.org@localhost>
To: Paul_Koning%Dell.com@localhost
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/51450 (tcptraceroute stopped working properly in 6.0 ->
 7.0 transition)
Date: Tue, 30 Aug 2016 16:18:32 +0200 (CEST)

 >> Problem fixed; was wrong types in evel/libnet10 (not explictly sized=
 ),
 >> causing an LP64 bug.  So not a kern bug after all.
 > =
 
 > Are the relevant struct packed?  If not, might there be other
 > instances of this issue caused by target-dependent struct
 > padding?  For example, I remember that the default alignment
 > for some data types (like int64_t) is different on Intel than
 > on RISC processors.
 
 The structs were not packed.  Inside our source tree, <sys/cdefs.h>
 defines __packed for this purpose, while outside our source tree (as
 here), it's a little more sketchy.  Therefore I've locally added
 
 +/* If you've not made __packed visible yet, too bad... */
 +#ifndef __packed
 +#define __packed       /* ignore */
 +#endif
 +
 
 to that header and marked all the structs with __packed; should I
 commit that update as well?
 
 Not that it would make any difference for any of our platforms,
 since the conversion I did was
 
 u_long -> uin32_t
 u_short -> uint16_t
 
 and I left u_char alone, even though it could be replaced with
 uint8_t.  Anyway, differences in alignment rules for 64-bit types
 don't actually factor into the equation here.
 
 Regards,
 
 - H=E5vard