The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: <ron@ronnatalie.com>
To: "'TUHS'" <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] C++ / Kernel
Date: Fri, 24 Aug 2018 10:32:05 -0400	[thread overview]
Message-ID: <1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com> (raw)
In-Reply-To: <20180824141348.1NLUE%steffen@sdaoden.eu>

That's a different issue (as I alluded to in my post).   Alignment on
machines is a different problem.   Type "punning" isn't the problem, the
compiler is propely converting one
pointer type to another but the operand is not correctly aligned.   

In the case I'm referring to, the Univac and the HEP encode partial word
sizes in the pointer.    If you take the literal bits from one pointer to
another (as if you stored it in a union),
then you end up referring to the wrong sized operand in the subsequent
operation.    Had you converted it to void* or explicitly forced a
conversion wih the cast, the compiler 
would have taken care of converting the pointer for you.

It's very odd when you find the machine storing the WRONG SIZE operand from
the pointer type in use.
As I said, it wasn't hard to fix (just grep for all the afflicted unions),
but it took a bit of long kernel debug sessions to figure out what was
happening.

> -----Original Message-----
> From: Steffen Nurpmeso <steffen@sdaoden.eu>
> I have found the link in the history of my browser, the story was
> 
>   http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html
> 




  reply	other threads:[~2018-08-24 14:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-23 14:42 ron
2018-08-23 17:24 ` Clem Cole
2018-08-23 20:21 ` Bakul Shah
2018-08-23 22:17   ` ron
2018-08-23 22:28     ` Nevin Liber
2018-08-23 22:48       ` Clem Cole
2018-08-23 23:14     ` Steffen Nurpmeso
2018-08-24 14:13       ` Steffen Nurpmeso
2018-08-24 14:32         ` ron [this message]
2018-08-24 18:15           ` Steffen Nurpmeso
2018-08-26 16:34             ` Paul Winalski
2018-08-27 16:31               ` Steffen Nurpmeso
2018-08-24  1:41     ` Bakul Shah
2018-08-24 10:41       ` Pete Turnbull
2018-08-24 12:17       ` ron
2018-08-24 18:36         ` Bakul Shah
2018-08-24 18:38           ` ron
2018-08-24  1:58     ` Dan Cross
2018-08-24  3:04       ` Clem cole
2018-08-24 14:01         ` Dan Cross
2018-08-24 13:22 ` Derek Fawcus
2018-08-24 16:59   ` Steffen Nurpmeso
2018-08-23 23:29 Noel Chiappa
2018-08-23 23:42 ` ron
2018-08-24  0:30   ` Clem Cole
2018-08-24  2:05     ` Bakul Shah
2018-08-24 12:21     ` ron
2018-08-24  1:27 Noel Chiappa
2018-08-24  2:52 ` Clem cole
2018-08-24  7:30 Paul Ruizendaal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='1f6201d43bb7$3b9ebde0$b2dc39a0$@ronnatalie.com' \
    --to=ron@ronnatalie.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).