What should "*nft = *(struct need_to_free *) ntf->addr;" do?

[Pete Delany]

    Would someone forward this to Dennis Ritchie, unfortunately I havn't his
    e-mail address.  I just made a 100DM bet that the code found in heap_kmem.c
    check_need_to_free() is correct where it copies a structure pointed to by
    a structure onto the first structure with structure assignment:
    {
	struct need_to_free {
		struct need_to_free	*addr;
		int			nbytes;
		} *ntf = &kmem_info.need_to_free_list;

	*ntf = *(struct need_to_free *) ntf->addr;
    }

	        +-------------+        +------------+        +-------------+
		|             |        |            |        |             |
	ntf ->	|  addr p1 ----------> |   addr p2 ------->  |    addr p3  |
		|             |        |            |        |             |
		+-------------+        +------------+        +-------------+
		|             |        |            |        |             |
		|  nbytes n1  |        |  nbytes n2 |        |  nbytes n3  |
		|             |        |            |        |             |
		+-------------+        +------------+        +-------------+


    So after the structure should the data structure look like my humble view:
							       ==============

	        +-------------+        +------------+        +-------------+
		|             |        |            |        |             |
	ntf ->	|  addr p2 ----------> |   addr p3 ------->  |    addr p4  |
		|             |        |            |        |             |
		+-------------+        +------------+        +-------------+
		|             |        |            |        |             |
		|  nbytes n2  |        |  nbytes n3 |        |  nbytes n4  |
		|             |        |            |        |             |
		+-------------+        +------------+        +-------------+

    or like my friend thinks "undeterministic", and is this case 
    generating code that leaves the structures looking like:

	        +-------------+        +------------+        +-------------+
		|             |        |            |        |             |
	ntf ->	|  addr p2 ----------> |   addr p3 ------->  |    addr p4  |
		|             |        |            |        |             |
		+-------------+        +------------+        +-------------+
		|             |        |            |        |             |
		|  nbytes n3  |        |  nbytes n4 |        |  nbytes n5  |
		|             |        |            |        |             |
		+-------------+        +------------+        +-------------+


    is just a "feature". Ckecking out the ANSII Oct 31 '88 spec says:

	"If the value being stored in an object is accessed from another 
	object that overlaps in any way the storage of the first object, 
	then the overlap shall be exact and the two objects shall have
	qualified or unqualified versions of a compatible type; 
	otherwise the behavior is undefined"

	Now to better understand this let us assume:
	============================================
	1. a structure and an object are the same thing,
	   object is just a OSI'ish term,

	2. "in any way" add nothing to the logic of the statement,

	3. "ANYTHING or unANYTHING" add nothing to the meaning,

	4. overlap storage means overlaping in memory, not symboliclly
	   in the intermediate language of the compiler or it's authors,

	Then we get the following slightly more understandable statement:
	=================================================================
	"If the data being stored in a structure is accessed from another 
	structure that overlaps the memory storage of the first structure, 
	then the overlap shall be exact and the two structures shall have
	versions of a compatible type; otherwise the behavior is undefined"

	Now, breaking it into it's structural components, we get:
	=========================================================

	"If 	the data being stored in a structure is accessed 
		from another structure : TRUE
	and  
		that data overlaps the memory storage of the 
		first structure : TRUE, 
     
	then  
		the overlap shall be exact: TRUE 
		and the two structures shall have
		versions of a compatible type; :TRUE
	      
	otherwise  
		"the behavior is undefined"


	This this reduces to:
		if(TRUE && TRUE) 
			TRUE;	/* OK */
		
	So  my interpretation is the behavior is OK.  How about
	it Dennis?  I talked to you about 15 years ago when I was
	upgrading our V6 Honewell Compiler to V7 to do structure 
	assignment and think it would have done it as I see reasonable
	now. System V, BSD4.3, Sun, and Vax compiler seem to have 
	avoided this bug, so I assume most people expect the structure
	to be assigned as if done with bcopy().  

	I don't see the fix being as easy as on Steve Bunches,
	Dennis's or Johnsons compilers but I do feel it
	is a bug and not a "feature". What do you guys think?

	How many people know of existing code that uses this 
	kind of assumpion? Is there much code out there.  This
	kmem_alloc() bug has been irritating me for almost a year

SUMMARY:
	Want opinions from C compiler guru's about what "C" should do.  
	I currently think Dennis is the best authority on C. How about
	our C++ gurus at the Labs; what should C++ do?  And last, but not
	least, how about our ANSII C committee types, am I interpreting 
	your gospel as it was intended by the almighty? If not a lexical
	breakdown might be insighfull. 

DISCLAIMER:
	Of course my opinion is not likely the same as Siemens, 
	Nixdorf, OSI, ANSII, XOPEN, OSF, or any of the world authorities.
	However opinions from all are appreciated, especially those
	helping me win my 100 DM. :-)