home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / sun / misc / 3983 < prev    next >
Encoding:
Text File  |  1992-08-29  |  3.3 KB  |  95 lines

  1. Xref: sparky comp.sys.sun.misc:3983 comp.lang.c:12906
  2. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  3. From: torek@horse.ee.lbl.gov (Chris Torek)
  4. Newsgroups: comp.sys.sun.misc,comp.lang.c
  5. Subject: Re: Strange error in C compiler
  6. Date: 28 Aug 1992 10:56:06 GMT
  7. Organization: Lawrence Berkeley Laboratory, Berkeley
  8. Lines: 80
  9. Message-ID: <25820@dog.ee.lbl.gov>
  10. References: <13271.714953297@kiae.su>
  11. Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
  12. NNTP-Posting-Host: 128.3.112.15
  13. Keywords: dynamic linking C compilation constant pointer
  14.  
  15. In article <13271.714953297@kiae.su> leo@ipmce.su writes:
  16. >extern _DYNAMIC[];
  17.  
  18. Names beginning with an underscore followed by an uppercase letter
  19. or another underscore are defined as ``reserved to the implementation''.
  20. Thus, as far as the C language is concerned, the behavior of this (and
  21. anything else in the program, given this) is undefined.
  22.  
  23. >main() {
  24. >    if (_DYNAMIC)
  25. >        puts("Dynamic");
  26. >    else
  27. >        puts("Static");
  28. >}
  29.  
  30. >[The compiler completely eliminates the else clause as dead code; why?]
  31.  
  32. If we were to change this to
  33.  
  34.     #include <stdio.h>
  35.     #include <stdlib.h>
  36.     extern int A[];
  37.     int main(void) {
  38.         if (A)
  39.             puts("Dynamic");
  40.         else
  41.             puts("Static");
  42.         exit(0);
  43.     }
  44.  
  45. and then compile it with a module that defines the array A[], we might
  46. *expect* the compiler to omit the ``else'' clause (and, one hopes, warn
  47. that the second puts() call is unreachable).  By definition, the ``value''
  48. of an array object is the address of its first element, so this test is
  49. identical to:
  50.  
  51.         if (&A[0] != NULL)
  52.  
  53. The C language guarantees that no ``normal'' pointer value, including
  54. those arising from ``&object'' constructs, compares equal to NULL, so
  55. this is logically equivalent to:
  56.  
  57.         if (1)
  58.  
  59. and the code in main() can therefore be rewritten as:
  60.  
  61.         puts("Dynamic");
  62.         goto done;
  63.         puts("Static");
  64.     done:
  65.         exit(0);
  66.  
  67. >... with if-statement rewritten as ``if (_DYNAMIC != (int*) 0)'' [the
  68. >else clause is retained and the program functions as intended under
  69. >SunOS].  Could anyone explain why?
  70.  
  71. Answering ``why'' questions is impossible in general.  A surface reason
  72. is ``because the compiler is written that way''.  By using the name
  73. ``_DYNAMIC'' you have bought into ``undefined behavior'', and the
  74. system can do as it pleases.  If it wants to eliminiate dead code based
  75. only on syntax rather than ``logical'' consequences of ``if this were a
  76. defined behavior and acted like other defined behaviors'', that is just
  77. the way it goes.
  78.  
  79. This of course invites wondering why the compiler is written that way.
  80. Only the compiler's author(s) can answer this.  Laziness?  Obstinacy?
  81. A need to test _DYNAMIC in vendor library code?  A bug in the optimizer?
  82. There are many possibilities, and there is no real point in speculation.
  83.  
  84. If you have some real need to test _DYNAMIC, you will have to execute
  85. that test outside the scope of the C language.  Once you commit to
  86. this, whatever works is fair game.  Of course, any dependence on
  87. undocumented compiler behavior is an invitation to sorrow: your code
  88. may fail under the next release.  You might want to stick with
  89. something documented, such as an interface to assembler.  At least in
  90. assembler, you can test absolute symbols without worrying about the
  91. compiler optimizing it out.
  92. -- 
  93. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  94. Berkeley, CA        Domain:    torek@ee.lbl.gov
  95.