Source-Changes-D archive

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

Re: CVS commit: src/sys/arch/atari/stand/installboot



> It's access via two different pointers, which happen to have the same
> bits by virtue of being stored in a union -- the union doesn't
> actually do anything about aliasing of the pointed-to object, except
> probably confuse gcc.
> 
> The point is that you can't get at one object in memory through two
> pointers of different types (except to get at a non-char object via a
> char pointer).
> 
> The compiler sometimes tries to detect when you're violating this
> rule, but it can't always -- casting through void *, or passing the
> pointer through a union of pointer types, may suppress warnings, but
> will still violate the rule.

Then what's your point? 
Should we always strictly use memcpy even in MD code you won't maintain?

If you really don't like current code, I'd still like to keep
the original casts with -fno-strict-aliasing, instead of memcpy
because my goal is just "to switch m68k ports to using gcc48 by default
in netbsd-7," not playing with modern compiler and C specifications.

> Changing `*(uint16_t *)p = v' to `memcpy(p, &v, 2)' doesn't change any
> of that.

The formar can be easily changed
 *(uint16_t *)p = htobe16(v);
but the latter can't. You might be able to use functions like
host16enc and target16enc for streaming data, but the target
cksum is not stream but just calculated in uint16_t.

---
Izumi Tsutsui


Home | Main Index | Thread Index | Old Index