🚀 go-pugleaf

msb@sq.sq.com (Mark Brader) writes:
>> > Does ANSI say that structure assignment is done by member-wise copy or
>> > by bit-wise copying?
>(As I said earlier, I do not believe that the answer to this is clear.)
>> How would a standard-conforming program tell the difference?
>Since the bitwise copy is a superset of the member-wise copy, a conforming
>program might be able to tell the difference *only if* the standard
>requires bitwise copying and the implementation copies member-wise.

And *if* the Standard required programs to have wheels, "cat.c" would be
a station wagon.  I don't see any hint in the Standard that bitwise copying
is required.  I do find that:

	(3.5.2.1) "As discussed in 3.1.2.5, a structure is a type consisting
	of a sequence of named members, whose storage is allocated in an
	ordered sequence..."
	(3.1.2.5) "A _structure type_ describes a sequentially allocated
	nonempty set of member objects, each of which has an optionally
	specified name and possibly distinct type."
	[ note that 3.5.2.1 specifies that the unnamed *member objects*
	must be bit-field members ]

So, I would argue that while a structure *object* may contain unnamed internal
padding, the *type* does not.  So, when a structure *value* is evaluated,
because it has an associated *type*, the *value* does not (logically) contain
padding, and need not be copied when the = operator drops it into its
destination.

Failing any words from the standard to the contrary, I conclude that any
program which depends on bitwise copying of compiler-inserted padding is
depending on something for which the standard omits any explicit definition of
behavior, and therefore the program opens up the Pandora's Box of Undefined
Behavior (1.6).