home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / std / c / 2591 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  2.0 KB
  1. Path: sparky!uunet!world!ksr!jfw
  2. From: jfw@ksr.com (John F. Woods)
  3. Newsgroups: comp.std.c
  4. Subject: Re: How is struct assignment defined (idle query)?
  5. Message-ID: <15576@ksr.com>
  6. Date: 8 Sep 92 13:19:44 EDT
  7. References: <715547606snx@grendel.demon.co.uk> <Bu3FMw.II4@sneaky.lonestar.org> <1992Sep5.165014.7366@sq.sq.com>
  8. Sender: news@ksr.com
  9. Lines: 33
  10.  
  11. msb@sq.sq.com (Mark Brader) writes:
  12. >> > Does ANSI say that structure assignment is done by member-wise copy or
  13. >> > by bit-wise copying?
  14. >(As I said earlier, I do not believe that the answer to this is clear.)
  15. >> How would a standard-conforming program tell the difference?
  16. >Since the bitwise copy is a superset of the member-wise copy, a conforming
  17. >program might be able to tell the difference *only if* the standard
  18. >requires bitwise copying and the implementation copies member-wise.
  19.  
  20. And *if* the Standard required programs to have wheels, "cat.c" would be
  21. a station wagon.  I don't see any hint in the Standard that bitwise copying
  22. is required.  I do find that:
  23.  
  24.     (3.5.2.1) "As discussed in 3.1.2.5, a structure is a type consisting
  25.     of a sequence of named members, whose storage is allocated in an
  26.     ordered sequence..."
  27.     (3.1.2.5) "A _structure type_ describes a sequentially allocated
  28.     nonempty set of member objects, each of which has an optionally
  29.     specified name and possibly distinct type."
  30.     [ note that 3.5.2.1 specifies that the unnamed *member objects*
  31.     must be bit-field members ]
  32.  
  33. So, I would argue that while a structure *object* may contain unnamed internal
  34. padding, the *type* does not.  So, when a structure *value* is evaluated,
  35. because it has an associated *type*, the *value* does not (logically) contain
  36. padding, and need not be copied when the = operator drops it into its
  37. destination.
  38.  
  39. Failing any words from the standard to the contrary, I conclude that any
  40. program which depends on bitwise copying of compiler-inserted padding is
  41. depending on something for which the standard omits any explicit definition of
  42. behavior, and therefore the program opens up the Pandora's Box of Undefined
  43. Behavior (1.6).
  44.