Re: [TUHS] C++ / Kernel

ron(a)ronnatalie.com wrote in <151301d43b2f$07881ed0$16985c70$(a)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)