home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3308 < prev    next >
Encoding:
Text File  |  1993-01-01  |  7.3 KB  |  168 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!wupost!spool.mu.edu!umn.edu!csus.edu!netcom.com!rfg
  3. From: rfg@netcom.com (Ronald F. Guilmette)
  4. Subject: Re: Standard conformance and GCC 2.3.3
  5. Message-ID: <1993Jan1.114912.22617@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <C04EEM.4K@jrd.dec.com>
  8. Date: Fri, 1 Jan 1993 11:49:12 GMT
  9. Lines: 157
  10.  
  11. In article <C04EEM.4K@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
  12. +An e-mail correspondant advised that GCC's -pedantic-errors option is virtually
  13. +(if not actually) documented as yielding a non-conforming implementation.
  14.  
  15. Here is the description of that option from the GCC 2.0 manual:
  16.  
  17.     -pedantic    Issue all the warnings demanded by strict ANSI
  18.             standard C; reject all programs that use forbidden
  19.             extensions.
  20.  
  21.     -pedantic-errors
  22.             Like -pedantic except that errors are produced
  23.             rather than warnings.
  24.  
  25. I believe that the word "warning" is being misused in these statements, and
  26. that we should imagine that the word "diagnostic" had been used instead.  I
  27. believe that this reflect Richard Stallman's true intent.
  28.  
  29. Now let me briefly respond to a few of Norman's other points.  (My last
  30. response below contains some potentially interesting fodder for the *real*
  31. language lawyers out there.)
  32.  
  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. This is not a standards comformance issue, and so I will belabor it no further
  40. in this forum.  I should never have raised it here in the first place.
  41.  
  42. +----------
  43. +Ron Guilmette:
  44. +>For any such test case that you may devise, a standard conforming compiler
  45. +>may (at its discression) issue one or more disgnostics[...]
  46. +
  47. +I'd say you showed much more discretion in your invention of "disgnostics"
  48. +than in "discression."  False spurious diagnostics should indeed be refered
  49. +to as "disgnostics."  Lovely word!
  50.  
  51. I will work on my spelling.
  52.  
  53. +----------
  54. +Ron Guilmette:
  55. +>unsigned long overflow = LONG_MAX + 3; /* ERROR */
  56. +
  57. +Norman Diamond:
  58. +>Again I see no violation of a constrant.
  59. +
  60. +Ron Guilmette:
  61. +>The Technical Information Bulletin #1 (RFI #31) issued by x3j11 makes it
  62. +>clear that it is x3j11's interpretation that this contains a constraint
  63. +>violation (of the second constraint given in 3.4).
  64. +
  65. +Sigh.  But wait!  Do you have the RFI's on line?
  66.  
  67. No, but they should be available from x3j11.
  68.  
  69. +----------
  70. +Ron Guilmette:
  71. +>#5)  GCC incorrectly issues an error for the following standard-conformant
  72. +>     code.  (Note that `wchar_t' is the same as type `long int' on i486-svr4
  73. +>typedef long int wchar_t;
  74. +>wchar_t array5[4] = L"abcd";
  75. +
  76. +[later]
  77. +>Norman has incorrectly presumed that GCC's error in this case has something
  78. +>to do with the definition of the type `wchar_t'.  In fact that is entirely
  79. +>besides the point.  The above code is accepted by GCC 2.3.3 if the explicit
  80. +>array size is changed from `4' to `5'.
  81. +
  82. +I still think the implementation is allowed to play dirty pool...
  83.  
  84. As I have previously noted, standard conformant implementations are allowed
  85. (due to the abundant loosness in the ANSI C standard) to issue what I would
  86. characterize as "too many" diagnostics... but they are not allowed to issue
  87. too few.  A conformant implementation may issue a diagnostic because it
  88. does not like the way your hair is parted.  It may not however fail to
  89. issue a required diagnostic, regardless of how you part your hair.
  90.  
  91. Because implementations are permitted (by the standard) to issue diagnostics
  92. for any arbitrary condition, or for any arbitrary input translation unit,
  93. no "bug report" suggesting that a given implementation gave "too many"
  94. errors for some given piece of code can be anything other than a comment about
  95. the "quality of implementation" provided.  (And that it all I intended this
  96. to be.)
  97.  
  98. While I am not happy that the framers of the ANSI C standard choose to
  99. provide implementors with a legal way to (in effect) get away with murder,
  100. I accept the standard as it is, and I acknowledge that any reports I may
  101. have posted here (or which I may post in the future) which claim that
  102. such-and-such a compiler is rude (because it issues "too many" errors) are
  103. really only comments about the "quality" of the implementation in question.
  104.  
  105. +----------
  106. +Regarding #6, we agreed that GCC failed, though we disagreed on the reason and
  107. +on what results we think should be correct.  It would be nice if Mr. Guilmette
  108. +had followed that thread, not just my wisecrack about the disgnostic.
  109.  
  110. Case #6 was indeed interesting.  Here it is again:
  111.  
  112.     extern volatile struct s evs;
  113.     void evs_test () { evs; }
  114.  
  115. I'm glad that Norman agrees that GCC failed this case (a fact which always
  116. seemed rather evident to me, especially since the compiler outright crashed).
  117.  
  118. In this example, an identifier which designates an object which has an
  119. incomplete type is used within an expression.
  120.  
  121. Even after reading the first sentence in the "semantics" subsection of
  122. section 3.3.1, and looking at the syntax rules given just above that, I
  123. am not able to state with total certainty that this example either does or
  124. does not violate the syntax rules given in 3.3.1.  It seems to me that
  125. the whole issue (of the validity or invalidity of the above code) rests
  126. upon one's interpretation of the first "semantics" sentence in 3.3.1.
  127. It says:
  128.  
  129.     "An identifier is a primary expression provided it has been
  130.     declared as designating an object (in which case it is an lvalue
  131.     or a function (in which case it is a function designator)."
  132.  
  133. Does the identifier which forms the expression in the above code "designate
  134. an object" even though its type is an incomplete type (rather that an
  135. object type)?
  136.  
  137. I think the answer to that question is "yes", the identifier *does* designate
  138. an object (which perhaps has a complete type in some other translation unit
  139. of the program), but I still think that the above code it blatantly wrong
  140. (from a strictly pragmatic standpoint) and I would have liked it if the
  141. stabndard has indicated exactly that in a clear fashion.
  142.  
  143. I guess what I'm saying is that I think x3j11 messed up on this small point.
  144. I think the standard should have said ""An identifier is a primary expression
  145. provided it has been declared as designating an object *and* providing
  146. the type of the identifier is an object type..."
  147.  
  148. Perhaps some current and/or former member of x3j11 would care to comment.
  149.  
  150. P.S.  Note that `volatile' has no well-defined meaning (as far as the
  151. standard is concerned) so the presence or absence of the `volatile'
  152. qualifier in the above example is not directly relevant to the validity
  153. or invalidity of the code (which would be the same either with or without
  154. the volatile qualifier in there).  I just put in the `volatile' qualifier
  155. because that (apparently) is the one extra kicker needed to entice GCC
  156. into crashing.
  157.  
  158. -- 
  159.  
  160. // Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
  161. //
  162. //      "On the one hand I knew that programs could have a compelling
  163. //       and deep logical beauty, on the other hand I was forced to
  164. //       admit that most programs are presented in a way fit for
  165. //       mechanical execution, but even if of any beauty at all,
  166. //       totally unfit for human appreciation."
  167. //                                              -- Edsger W. Dijkstra
  168.