The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: <ron@ronnatalie.com>
Cc: 'TUHS' <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] C++ / Kernel
Date: Fri, 24 Aug 2018 01:14:13 +0200	[thread overview]
Message-ID: <20180823231413.QeahD%steffen@sdaoden.eu> (raw)
In-Reply-To: <151301d43b2f$07881ed0$16985c70$@ronnatalie.com>

ron@ronnatalie.com wrote in <151301d43b2f$07881ed0$16985c70$@ronnatalie.com>:
  ...
 |This union was right in the middle of the buf struct:
 |
 | union {
 |     caddr_t b_addr;          /* low order core address */
 |     int      *b_words;               /* words for clearing */
 |     struct filsys *b_filsys; /* superblocks */
 |     struct dinode *b_dino;   /* ilist */
 |     daddr_t *b_daddr;                /* indirect block */
 |} b_un;
 |There were a number of other places that did the same thing.   It's
 |OFFICIALLY now in undefined behavior by the standard (though of course that
 |didn't exist in the BSD days) ,
 |to store in one element of the union and retrieve it via another.   This is
 |one of the reasons why.

Luckily "type punning" is possible.  Ach, what do i know;
nonetheless, i think it is a terrible direction that C goes to,
now you often need memcpy() to local storage instead of a simple
assignment (with a cast) in order to avoid undefined behaviour
that allows compilers to do bad things.  On a NetBSD list there
was a link to such a story not too long ago, the resulting
C standard compliant code was ridiculous, the last string of fun
has been screwed out of C.  Unfortunately i have not saved the
message, but Christos Zoulas has been the author.

Regarding "type punning" the standard C 2011 says (6.5.2.3)

  If the member used to read the contents of a union object is not
  the same as the member last used to store a value in the object,
  the appropriate part of the object representation of the value
  is reinterpreted as an object representation in the new type as
  described in 6.2.6 (a process sometimes called ‘‘type
  punning’’). This might be a trap representation.

This has not changed in C 2018 (though i have only version 2017
ballot).  So as long as the type sizes are identical anything
should be fine.  Just as you say.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

  parent reply	other threads:[~2018-08-23 23:21 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 [this message]
2018-08-24 14:13       ` Steffen Nurpmeso
2018-08-24 14:32         ` ron
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=20180823231413.QeahD%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    --cc=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).