home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18431 < prev    next >
Encoding:
Text File  |  1992-12-15  |  2.9 KB  |  64 lines
  1. Newsgroups: comp.lang.c
  2. Path: sparky!uunet!europa.asd.contel.com!howland.reston.ans.net!usc!cs.utexas.edu!torn!watserv2.uwaterloo.ca!watmath!thinkage!atbowler
  3. From: atbowler@thinkage.on.ca (Alan Bowler)
  4. Subject: Re: Is this ANSI?
  5. Message-ID: <1992Dec15.204100.4293@thinkage.on.ca>
  6. Organization: /etc/organization
  7. References: <By6pC6.3u7@unx.sas.com> <1992Dec1.225840.719@thinkage.on.ca> <Byr66A.A2A@unx.sas.com>
  8. Date: Tue, 15 Dec 1992 20:41:00 GMT
  9. Lines: 53
  10.  
  11. In article <Byr66A.A2A@unx.sas.com> sasghm@theseus.unx.sas.com (Gary Merrill) writes:
  12. >
  13. >In article <1992Dec1.225840.719@thinkage.on.ca>, atbowler@thinkage.on.ca (Alan Bowler) writes:
  14. >|> >
  15. >|> >Nonsense.  See section 3.5.2.1: "Within a structure object, the
  16. >|> >non-bit-field members and the units in which bit-fields reside have
  17. >|> >addresses that increase in the order in which they are declared."
  18. >|> 
  19. >|> True.  The compiler is not free to juggle the order withing a
  20. >|> struct, but as a rule of thumb you you program as if it did have that
  21. >|> freedom.  Similarly, you should treat "union" as if the compiler was
  22. >|> free pretend it read "struct".
  23. >
  24. >Huh?  Why should you do this?  What do you gain by doing so?  Would
  25. >you care to justify these "rules of thumb"?  (There are some pretty
  26. >silly consequences to supposing that a compiler might really *not*
  27. >enforce the standard in this respect.  But right now I leave these
  28. >as an exercise for the reader.  As it is, the suggestion that one
  29. >ought to suppose that the compiler *fails* to implement an explicit
  30. >part of the standard is puzzling enough.)
  31. >
  32. Because at a later time you may want to reorder the structure so that
  33. it gives you better performance on a different machine.  If you have
  34. done things that depend on the order of objects within the struct,
  35. you will find it difficult to locate these dependancies.
  36.  
  37. >By the way, do you also (as a rule of thumb) program as if the
  38. >compiler might (for example) implement a long as a smaller type
  39. >than a short?
  40. >
  41. >And finally ... If you really *do* treat 'union' as though it might
  42. >mean 'struct' (although I confess I am not at all sure what it *means*
  43. >to treat 'union' in this way), you could be in *real* trouble since
  44. >sequences of operations guaranteed to succeed for structs will fail
  45. >for unions.
  46. What I meant is that except for machine dependant code, the program
  47. should only retrieve a value from a union element, if the last
  48. assignment to that union was to the SAME element name.  I know that
  49. there are things that are guaranteed to work on structs that will fail
  50. for unions.  I am not refering to these cases.  There are also some
  51. things that "work" if you have a union, but would fail if you had 
  52. a struct.  These should be avoided.
  53.      E.g.
  54.         union {
  55.             int i;
  56.             char c;
  57.         } u;
  58.  
  59.         u.i = 'a';
  60.         printf("%c", u.c);
  61. will "work" on some machines.   This is the sort of thing that should
  62. be avoided.  The last assignment to u was to u.i so only u.i or all
  63. of u should be accessed as a value.
  64.