NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: <>
To: <>
Cc: <>, <>
Subject: Re: kern/51450 (tcptraceroute stopped working properly in 6.0 ->
 7.0 transition)
Date: Tue, 30 Aug 2016 14:25:02 +0000

 > On Aug 30, 2016, at 10:18 AM, Havard Eidnes <> wrote:
 >>> 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 unless either there is no padding, or you make the padding explicit wit=
 h dummy fields.
 > 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.
 I think that 16 and 32 bit types are not a problem, while I know for a fact=
  that 64 bit types are.  If others can confirm I remember that correctly, t=
 hen we can leave it alone.

Home | Main Index | Thread Index | Old Index