On Sun, 21 Aug 2016, Slawa Olhovchenkov wrote:
On Sun, Aug 21, 2016 at 11:00:24PM +1000, Bruce Evans wrote:
On Sun, 21 Aug 2016, Slawa Olhovchenkov wrote:
On Sun, Aug 21, 2016 at 09:32:35PM +1000, Bruce Evans wrote:
...
*(foo_t *)asks for alignment bugs. We have already fixed lots of these
bugs for copying struct timevals in places like ping.c. Compilers warn
about misalignment when certain warnings are enabled, but only on arches
where misalignment is more than a pessimization. There is no reason why
td_retval would be always aligned on these arches. Alignment of 64-bit
types on 32-bit arches is usually so unimportant that even int32_t is
not required to be aligned by the ABI, and there is no point in
aligning td_retval specially unless you also do it for a large fraction
of 64-bit integers in the kernel, and there are negative points for
doing that.
For eliminate aligment bugs need to replace all assigment more then 1
bytes to *td_retval by memcpy?
The copying must be of size 1 or 2 ints unless you are making even larger
type puns than now. 1 int is obviously safe to just assign, and 2 ints
should use memcpy().
Why?
If it has size not 1 * sizeof(int) or 2 * sizeof(int) or is not an integer,
than it is had to assign to a 2-byte array and might need more careful
packing just to memcpy() it.
I am remeber about platforms with missaligment trap when
accessing int16 by odd address. Now platforms like this do not exist
anymore?
i386 still exists, and it supports trapping on misalignement for at least
CPL 3 (not kernel CPL 0). IIRC, amd64 drops support for this.
There are also endianness problems. The old version was even more broken
on big endian systems. The current version needs some magic to reverse
the memcpy() of the bits. We already depend on this for some 64-bit
syscalls like lseek().
Can you explain some more?
This is not transfer over network and don't read from external media.
Where is problem?
It is similar to a network transfer. It needs a protocol to pass values
to applications. Type puns are fragile even within a single compilation
unit.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
