home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3314 < prev    next >
Encoding:
Text File  |  1993-01-02  |  5.0 KB  |  103 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!decwrl!pa.dec.com!jrdzzz.jrd.dec.com!jit533.jit.dec.com!diamond
  3. From: diamond@jit533.jit.dec.com (Norman Diamond)
  4. Subject: Re: Standard conformance and GCC 2.3.3
  5. Message-ID: <C07vxJ.1Ex@jrd.dec.com>
  6. Sender: usenet@jrd.dec.com (USENET News System)
  7. Nntp-Posting-Host: jit533.jit.dec.com
  8. Reply-To: diamond@jit.dec.com (Norman Diamond)
  9. Organization: Digital Equipment Corporation Japan , Tokyo
  10. References: <C04EEM.4K@jrd.dec.com> <1993Jan1.114912.22617@netcom.com>
  11. Date: Sat, 2 Jan 1993 08:08:07 GMT
  12. Lines: 89
  13.  
  14. In article <1993Jan1.114912.22617@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
  15. >In article <C04EEM.4K@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
  16. >An e-mail correspondant advised that GCC's -pedantic-errors option is
  17. >>virtually (if not actually) documented as yielding a non-conforming impleme
  18.  
  19. >Here is the description of that option from the GCC 2.0 manual:
  20. >    -pedantic    Issue all the warnings demanded by strict ANSI
  21. >            standard C; reject all programs that use forbidden
  22. >            extensions.
  23. >    -pedantic-errors
  24. >            Like -pedantic except that errors are produced
  25. >            rather than warnings.
  26.  
  27. Neither of these asserts that a conforming implementation is invoked.
  28. If they invoke a non-conforming implementation, they can still reject
  29. programs on the basis of the implementor's personal aesthetics.
  30. This question still needs clarification.
  31.  
  32. >I will work on my spelling.
  33.  
  34. No problem.  I still think that "disgnostics" is a lovely word, and accurately
  35. describes false misleading spurious diagnostics :-)
  36.  
  37. >>>#5)  GCC incorrectly issues an error for the following standard-conformant
  38. >>>     code.  (Note that `wchar_t' is the same as type `long int' on i486-svr4
  39. >>>typedef long int wchar_t;
  40. >>>wchar_t array5[4] = L"abcd";
  41.  
  42. >>>Norman has incorrectly presumed that GCC's error in this case has something
  43. >>>to do with the definition of the type `wchar_t'.  In fact that is entirely
  44. >>>besides the point.  The above code is accepted by GCC 2.3.3 if the explicit
  45. >>>array size is changed from `4' to `5'.
  46.  
  47. >>I still think the implementation is allowed to play dirty pool...
  48. [Even though I no longer think this will excuse other possible trial cases.]
  49.  
  50. >A conformant implementation may issue a diagnostic because it
  51. >does not like the way your hair is parted.  It may not however fail to
  52. >issue a required diagnostic, regardless of how you part your hair.
  53.  
  54. We agree, but this is not the problem here.  You complained that it DID
  55. issue a diagnostic, one which is NOT required, and we were only wondering
  56. whether it was allowed to cause rejection.
  57.  
  58. >no "bug report" suggesting that a given implementation gave "too many"
  59. >errors for some given piece of code can be anything other than a comment about
  60. >the "quality of implementation" provided.  (And that it all I intended this
  61. >to be.)
  62.  
  63. We agree, and this is almost the problem.  However, I'm pretty sure that a
  64. similar trial program (where you #include one of the relevant standard headers
  65. instead of typedef'ing wchar_t yourself) will probably yield a rejection which
  66. is more than just "quality of implementation."  That will be worth reporting.
  67.  
  68. >Case #6 was indeed interesting.  Here it is again:
  69. >    extern volatile struct s evs;
  70. >    void evs_test () { evs; }
  71. >I'm glad that Norman agrees that GCC failed this case (a fact which always
  72. >seemed rather evident to me, especially since the compiler outright crashed).
  73. >In this example, an identifier which designates an object which has an
  74. >incomplete type is used within an expression. [...] It seems to me that
  75. >the whole issue (of the validity or invalidity of the above code) rests
  76. >upon one's interpretation of the first "semantics" sentence in 3.3.1.
  77. >    "An identifier is a primary expression provided it has been
  78. >    declared as designating an object (in which case it is an lvalue
  79. >    or a function (in which case it is a function designator)."
  80. >Does the identifier which forms the expression in the above code "designate
  81. >an object" even though its type is an incomplete type (rather that an
  82. >object type)?
  83.  
  84. I think you've found a bug in the standard.  An identifier with incomplete
  85. type is sometimes considered to designate an object and sometimes considered
  86. not to designate an object.  I think it is intended for programmers to be
  87. able to apply unary & to take the address of an incomplete-typed something,
  88. so the answer to your question seems to be "yes" for 3.3.1.
  89.  
  90. Regardless, the implementation-defined access to evs must be one that neither
  91. evaluates nor modifies evs, due to the definitions of what an expression does
  92. (the semantics of other sections on expressions).  This expression contains
  93. no operator that evaluates and no operator that modifies.  Therefore the size
  94. of the object does not have to be known, and the expression is valid.
  95.  
  96. >Perhaps some current and/or former member of x3j11 would care to comment.
  97.  
  98. I'd rather see the current COMMITTEE of x3j11 comment via RFI.
  99. --
  100. Norman Diamond                diamond@jit.dec.com
  101. If this were the company's opinion, I wouldn't be allowed to post it.
  102. Pardon me?  Or do I have to commit a crime first?
  103.