home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3301 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  6.5 KB
  1. Path: sparky!uunet!cs.utexas.edu!sun-barr!olivea!hal.com!decwrl!pa.dec.com!jrdzzz.jrd.dec.com!jit533.jit.dec.com!diamond
  2. From: diamond@jit533.jit.dec.com (Norman Diamond)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Standard conformance and GCC 2.3.3
  5. Message-ID: <C04EEM.4K@jrd.dec.com>
  6. Date: 31 Dec 92 10:56:46 GMT
  7. Sender: usenet@jrd.dec.com (USENET News System)
  8. Reply-To: diamond@jit.dec.com (Norman Diamond)
  9. Organization: Digital Equipment Corporation Japan , Tokyo
  10. Lines: 128
  11. Nntp-Posting-Host: jit533.jit.dec.com
  12.  
  13. An e-mail correspondant advised that GCC's -pedantic-errors option is virtually
  14. (if not actually) documented as yielding a non-conforming implementation.
  15. It turns all warnings into errors and causes compilation to be aborted, even
  16. for spurious-but-friendly (and spurious-but-unfriendly) warnings.  If this is
  17. true, Mr. Guilmette's first step should invoke a conforming implementation and
  18. post the results before this goes much further.
  19. ----------
  20. Ron Guilmette:
  21. >#8)  GCC fails to issue errors for the following erroneous code, even when
  22. >     the -pedantic-errors option is in effect.  [char shorter than int here]
  23. >void test_0 (char);
  24. >void test_0 (c) char c; { }
  25.  
  26. Norman Diamond:
  27. >I see no violation of a constraint.
  28.  
  29. An e-mail correspondent pointed out the constraint in ANSI Classic section 3.5,
  30. so GCC probably fails this test, and I failed it :-)
  31.  
  32. Ron Guilmette's #19 is in the same category as #8.
  33. ----------
  34. Ron Guilmette:
  35. >#7)  When compiling an empty source file while the -pedantic-errors option
  36. >     is in effect, GCC will generate an error message for a line number which
  37. >     does not actually exist in the source file.  (The line number indicated
  38.  
  39. Norman Diamond:
  40. >I believe that diagnostics are allowed to contain spurious line numbers unless
  41. >they follow a #line directive [...]
  42.  
  43. Chris Volpe:
  44. >I believe the diagnostics are allowed to say anything they want, and need not
  45. >even supply a line number. However, I don't understand the "unless they follow
  46. >a #line directive" part. Where does this come from?
  47.  
  48. If the vendor volunteers an implementation definition saying that diagnostics
  49. include line numbers, then a #line directive affects subsequent diagnostics.
  50. ANSI Classic section 3.8.4, page 94 lines 10 to 11:  "causes the implementation
  51. to behave as if the following sequence of source lines begins with a source
  52. line that has a line number as specified by the digit sequence".  In fact if
  53. the vendor volunteers such an implementation definition, then preceding
  54. diagnostics are also bound by lines 5 to 7 of the same section.  However, if
  55. the current token was not read during translation phase 1 (e.g. was created
  56. using the ## operator) then the standard is unhelpful.  And if the current
  57. token was read during translation phase 1 as part of a macro replacement
  58. string, then I'll bet every implementation in the world will get this wrong.
  59. Good thing that vendors don't have to volunteer non-spurious line numbers :-)
  60. ----------
  61. Ron Guilmette:
  62. >#9)  GCC fails to issue errors in cases where a static function is referenced
  63. >     but never defined, even when the -pedantic-errors option is used.
  64. >static void s (); int main () { s (); return 1; }
  65.  
  66. Norman Diamond:
  67. >Again I see no violation of a constraint.  Furthermore, if you returned
  68. >EXIT_SUCCESS instead of 1, I believe it would be strictly conforming.
  69. >Hard to believe, isn't it?  My best guess is that the invocation of s()
  70. >acts as a no-op.  The standard doesn't seem to permit any other behavior.
  71.  
  72. Chris Volpe:
  73. >Yeah, very hard to believe. Are you saying that all undefined functions must
  74. >behave as no-ops? Or is there something special about undefined static
  75. >functions?
  76.  
  77. I thought the standard failed to require definitions for static functions, but
  78. Ron Guilmette later pointed out that the second Constraints paragraph in ANSI
  79. Classic section 3.7 covers this.  I missed it while finding the Semantics
  80. paragraph that covered externals.  GCC probably fails and I failed.
  81. ----------
  82. Ron Guilmette:
  83. >#10)  GCC [-pedantic-errors] fails to issue an error for the following
  84. >void test () { func_ptr = i ? 0 : 0; }         /* ERROR */
  85.  
  86. Norman Diamond:
  87. >The code looks valid to me.  The conditional expression  i ? 0 : 0  is an
  88. >integral constant expression with value 0.
  89.  
  90. Whoops, it's an integral non-constant expression that happens to have value 0.
  91. The implementation is only allowed to evaluate one of those 0's, and doesn't
  92. know which one until run-time.  GCC probably fails and I failed.
  93. ----------
  94. Ron Guilmette:
  95. >For any such test case that you may devise, a standard conforming compiler
  96. >may (at its discression) issue one or more disgnostics[...]
  97.  
  98. I'd say you showed much more discretion in your invention of "disgnostics"
  99. than in "discression."  False spurious diagnostics should indeed be refered
  100. to as "disgnostics."  Lovely word!
  101. ----------
  102. Ron Guilmette:
  103. >unsigned long overflow = LONG_MAX + 3; /* ERROR */
  104.  
  105. Norman Diamond:
  106. >Again I see no violation of a constrant.
  107.  
  108. Ron Guilmette:
  109. >The Technical Information Bulletin #1 (RFI #31) issued by x3j11 makes it
  110. >clear that it is x3j11's interpretation that this contains a constraint
  111. >violation (of the second constraint given in 3.4).
  112.  
  113. Sigh.  But wait!  Do you have the RFI's on line?  If so, please e-mail them
  114. to me!  (Someone else who has them on-line ignored my request, sigh....
  115. I still have a subset of them, on two unreadable backup tapes, sighhhhhhhhh.)
  116. ----------
  117. Ron Guilmette:
  118. >#5)  GCC incorrectly issues an error for the following standard-conformant
  119. >     code.  (Note that `wchar_t' is the same as type `long int' on i486-svr4
  120. >typedef long int wchar_t;
  121. >wchar_t array5[4] = L"abcd";
  122.  
  123. [later]
  124. >Norman has incorrectly presumed that GCC's error in this case has something
  125. >to do with the definition of the type `wchar_t'.  In fact that is entirely
  126. >besides the point.  The above code is accepted by GCC 2.3.3 if the explicit
  127. >array size is changed from `4' to `5'.
  128.  
  129. I still think the implementation is allowed to play dirty pool, including
  130. being dirty enough to ACCEPT some of your efforts at random.  However, I think
  131. it's clear that you could construct another example which GCC would reject
  132. without excuse, and yes it seems clear now where GCC's failure is.
  133. ----------
  134. Regarding #6, we agreed that GCC failed, though we disagreed on the reason and
  135. on what results we think should be correct.  It would be nice if Mr. Guilmette
  136. had followed that thread, not just my wisecrack about the disgnostic.
  137. --
  138. Norman Diamond                diamond@jit.dec.com
  139. If this were the company's opinion, I wouldn't be allowed to post it.
  140. Pardon me?  Or do I have to commit a crime first?
  141.