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)
next prev 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).