On Thu, 17 Jan 2019 at 13:41, Philippe Mathieu-Daudé <phi...@redhat.com> wrote:
> On 1/17/19 12:50 AM, Samuel Thibault wrote:
> > --- a/slirp/slirp.c
> > +++ b/slirp/slirp.c
> > @@ -851,7 +851,7 @@ void slirp_input(Slirp *slirp, const uint8_t *pkt, int
> > pkt_len)
> > if (pkt_len < ETH_HLEN)
> > return;
> >
> > - proto = ntohs(*(uint16_t *)(pkt + 12));
> > + proto = (((uint16_t) pkt[12]) << 8) + pkt[13];
> > switch(proto) {
> > case ETH_P_ARP:
> > arp_input(slirp, pkt, pkt_len);
>
> What about using memcpy?
We should use whatever the new libslirp wants to consistently
use as its mechanism for loading unaligned data. I don't
suppose this is the only place where it ever needs to do this.
Personally I would vote for having libslirp have versions of
the ld*_p functions, because they solve the problem in a
clear and correct way. But that's up to Marc-André really.
(As you can see from clang build logs:
https://travis-ci.org/qemu/qemu/jobs/480813811
slirp/ has a lot of as-yet-unfixed "takes address of packed
member" bugs, which suggest it's a bit slapdash with
alignment. Running it under the clang sanitizer to look
for runtime alignment errors might also be interesting.)
thanks
-- PMM
