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: <Paul_Koning%Dell.com@localhost>
To: <he%NetBSD.org@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 14:25:02 +0000
> On Aug 30, 2016, at 10:18 AM, Havard Eidnes <he%NetBSD.org@localhost> wrote:
>=20
>>> Problem fixed; was wrong types in evel/libnet10 (not explictly sized),
>>> causing an LP64 bug. So not a kern bug after all.
>>=20
>> 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.
>=20
> 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
>=20
> +/* If you've not made __packed visible yet, too bad... */
> +#ifndef __packed
> +#define __packed /* ignore */
> +#endif
> +
>=20
> 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.
>=20
> Not that it would make any difference for any of our platforms,
> since the conversion I did was
>=20
> u_long -> uin32_t
> u_short -> uint16_t
>=20
> 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.
paul
Home |
Main Index |
Thread Index |
Old Index