home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / std / c / 3295 < prev    next >
Encoding:
Text File  |  1992-12-30  |  15.1 KB  |  337 lines
  1. Newsgroups: comp.std.c
  2. Path: sparky!uunet!paladin.american.edu!gatech!swrinde!sdd.hp.com!news.cs.indiana.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: <1992Dec30.202405.2227@netcom.com>
  6. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  7. References: <1992Dec30.011211.11409@netcom.com> <C02I8I.58I@jrd.dec.com>
  8. Date: Wed, 30 Dec 1992 20:24:05 GMT
  9. Lines: 326
  10.  
  11. I appreciate the efforts of everyone who has taken the time to look over
  12. the problem reports I have posted for GCC 2.3.3.
  13.  
  14. I'm forced to admit that several of my test cases are themselves buggy,
  15. but perhaps not quite as many as some people (e.g. Norman Diamond) have
  16. claimed.  Still, the discussion of these issues has been enlightening
  17. for me, and (I hope) for other folks as well.
  18.  
  19. When I made my posting, listing the things I felt that GCC 2.3.3 was not
  20. doing correctly, I probably should have clarified my approach and philosophy
  21. regarding C compiler testing.  This would have avoided a good deal of
  22. misunderstanding.
  23.  
  24. When testing ANSI C compilers, it is important to be aware of two "escape
  25. hatches" which are built into the ANSI C standard itself, and which can
  26. often make the testing process itself an exercize in futility.  These two
  27. escape hatches are:
  28.  
  29.     o    An implementation is allowed to issue "diagnostics" even in
  30.         the total absence of violations of the letter or the spirit
  31.         of the standard.  The effect of this rule (on testing) is
  32.         that it is essentially futile to write "positive" test cases
  33.         which attempt to verify that an implementation is "standard
  34.         conforming" by seeing if it "accepts" (presumably without
  35.         issuing diagnostics) a "standard conforming program".  For
  36.         any such test case that you may devise, a standard conforming
  37.         compiler may (at its discression) issue one or more disgnostics
  38.         regardless of the "conformance" of the code in question, and
  39.         the implementation may still be properly considered to be
  40.         "conformant".  Thus, the best a tester (such as myself) can
  41.         do is to write "positive" test cases which (at best) may
  42.         only be claimed to test "quality of implementation" (as
  43.         opposed to standard conformance).  This fact does not deter
  44.         me, and I *have* written a large number of such tests.  I
  45.         would have to agree however with anyone who might claim that
  46.         my posting of the results of any of these "positive" tests
  47.         to the comp.std.c newsgroup may have been inappropriate,
  48.         since "standard conformance" is not at issue when considering
  49.         these results.
  50.  
  51.         (By the way, I would hasten to note that the "official" U.S.
  52.         government test suite for C compilers also contains a signifi-
  53.         cant number of what I call "positive" tests.  I borrowed the
  54.         term "positive test" from the Ada compiler validation suite.)
  55.  
  56.     o    An implementation is allowed to define the term "diagnostic"
  57.         in any way it chooses.  Thus, the sudden implosion of the
  58.         video monitor on a microcomputer, workstation, or terminal,
  59.         followed by the splattering of the programmer which high
  60.         velocity shards of broken glass may be considered to be a
  61.         valid "diagnostic" (although a somewhat unfriendly one)
  62.         according the ANSI C standard.  Again, in my testing of C
  63.         compilers, I am forced by practical considerations to use
  64.         a somewhat more restrictive (and more traditional) definition
  65.         of the term "diagnostic", and my results reflect that
  66.         approach.  I trust that readers of comp.std.c will forgive
  67.         me if (for practical reasons) I do not consider compiler
  68.         crashes, implosions of monitors, or solar eclipses to be
  69.         examples of valid "diagnostics" (even though all such events
  70.         might alert me to potential problems ahead).
  71.  
  72. With all that said, let me now respond in detail to the issues raised by
  73. Normal Diamond with respect to me earlier posting.  In many cases, I'm
  74. forced to agree with Norman, while in others, I must respectfully disagree.
  75.  
  76. -------------------------------------------------------------------------
  77. In article <C02I8I.58I@jrd.dec.com> diamond@jit.dec.com (Norman Diamond) writes:
  78. +In article <1992Dec30.011211.11409@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
  79. +>-----------------------------------------------------------------------------
  80. +>#1)  GCC [-pedantic-errors] fails to detect the error in the following code
  81. +>void foo () {
  82. +>  extern void bar (int i, ...);
  83. +>  bar (99, 88, 77);
  84. +>}
  85. +>void bar (int i, int j, int k) { }      /* ERROR */
  86. +
  87. +The call is irrelevant.
  88.  
  89. I agree.  For this case, the behavior is undefined.  I have moved this test
  90. case to my "undefined behavior" pile.
  91.  
  92. +>-----------------------------------------------------------------------------
  93. +>#2)  GCC [-pedantic-errors] fails to detect the error in the following code
  94. +>unsigned long overflow = LONG_MAX + 3; /* ERROR */
  95. +
  96. +Again I see no violation of a constrant.
  97.  
  98. The Technical Information Bulletin #1 (RFI #31) issued by x3j11 makes it
  99. clear that it is x3j11's interpretation that this contains a constraint
  100. violation (of the second constraint given in 3.4).
  101.  
  102. +>-----------------------------------------------------------------------------
  103. +>#3)  GCC incorrectly flags an error on the following standard-conformant code
  104. +>     when the -pedantic-errors option is in effect.
  105. +>typedef int T;
  106. +>void test_1 (int T) { }
  107. +
  108. +Spurious diagnostics are allowed.
  109.  
  110. Correct.  This is a "quality of implementation" issue.  The code is conformant,
  111. so I believe that most users would prefer *not* to have a diagnostic.
  112.  
  113. +>-----------------------------------------------------------------------------
  114. +>#4)  On x86 machines, GCC fails to properly implement explicit floating-point
  115. +>     casts of those floating-point expressions which get evaluated using the
  116. +>     (internal) 80-bit floating-point format.
  117. +
  118. +This might well be true, but your example didn't test for it.  You only cast
  119. +a double operand to type double.
  120.  
  121. This is an interesting point.  The "nominal" type of and expression like
  122. `x*x' (where `x' has type double) is `double' but the standard explicitly
  123. allows the evaluation of such an expression to be performed using some
  124. wider flotaing-point data type.  This is exactly what occurs on x86 machines.
  125. Floating-point expressions are generally evaluated using the FP registers,
  126. and those registers in effect hold type `long double' values.  So on an
  127. x86 machine, the expression `x*x' actually has type `long double'.  Readers
  128. interested in further information on this topic are advised to obtain the
  129. "Floating Point C Extensions" document from x3j11.1, as it goes into far
  130. more detail in describing existing implementations.
  131.  
  132. +>-----------------------------------------------------------------------------
  133. +>#5)  GCC incorrectly issues an error for the following standard-conformant
  134. +>     code.  (Note that `wchar_t' is the same as type `long int' on i486-svr4.)
  135. +>typedef long int wchar_t;
  136. +>wchar_t array5[4] = L"abcd";
  137. +
  138. +This is a tough call.  ANSI Classic section 4.1.5 says that <stddef.h> defines
  139. +the type wchar_t...
  140.  
  141. Norman has incorrectly presumed that GCC's error in this case has something
  142. to do with the definition of the type `wchar_t'.  In fact that is entirely
  143. besides the point.  The above code is accepted by GCC 2.3.3 if the explicit
  144. array size is changed from `4' to `5'.  I hope that clarifies what the
  145. actual problem is.
  146.  
  147. +>-----------------------------------------------------------------------------
  148. +>#6)  The following erroneous code causes GCC to crash with a signal 6.
  149. +>extern volatile struct s evs;
  150. +>void evs_test () { evs; }
  151. +
  152. +The standard doesn't require diagnostics to be in a natural human language :-)
  153.  
  154. Correct.  As I noted above, exploding video monitors may be considered to
  155. be valid diagnostics according to the ANSI C standard.  Unfortunately, I have
  156. yet to develop a programmatic method (for use in my test suite) to determine
  157. unambiguously whether or not my workstation monitor has exploded.
  158.  
  159. +>-----------------------------------------------------------------------------
  160. +>#7)  When compiling an empty source file while the -pedantic-errors option
  161. +>     is in effect, GCC will generate an error message for a line number which
  162. +>     does not actually exist in the source file.
  163. +
  164. +I believe that diagnostics are allowed to contain spurious line numbers...
  165.  
  166. Correct.  This is another "quality of implementation" issue.
  167.  
  168. +>-----------------------------------------------------------------------------
  169. +>#8)  GCC [-pedantic-errors] fails to issue errors for the following
  170. +>void test_0 (char);
  171. +>void test_0 (c) char c; { }
  172. +
  173. +Again (as in #1) I see no violation of a constraint.
  174.  
  175. See ANSI section 3.5, third paragraph in the "constraints" section.
  176.  
  177. +>-----------------------------------------------------------------------------
  178. +>#9)  GCC fails to issue errors in cases where a static function is referenced
  179. +>     but never defined, even when the -pedantic-errors option is used.
  180. +>static void s (); int main () { s (); return 1; }
  181. +
  182. +Again I see no violation of a constraint.
  183.  
  184. See ANSI section 3.7, second paragraph in the "constraints" section.
  185.  
  186. +>-----------------------------------------------------------------------------
  187. +>#10)  GCC [-pedantic-errors] fails to issue an error for the following invalid
  188. +>void (*func_ptr) ();
  189. +>int i;
  190. +>void test () { func_ptr = i ? 0 : 0; }         /* ERROR */
  191. +
  192. +The code looks valid to me.  The conditional expression  i ? 0 : 0  is an
  193. +integral constant expression with value 0.
  194.  
  195. No.  It isn't.  It also doesn't qualify as a null pointer constant.  Thus,
  196. the constraint given in 3.3.16.1 applies to this case.
  197.  
  198. +>-----------------------------------------------------------------------------
  199. +>#11)  GCC fails to issue errors for the following invalid C code involving
  200. +>      comparison operators, even when the -pedantic-errors option is used.
  201. +[Much editing by N.D.]
  202. + int b_array_src[3];
  203. + extern int u_array_src[];
  204. +>int i;
  205. +>void test_relational_operators () {
  206. +>  i = & u_array_src > & b_array_src;            /* ERROR */
  207. +>}
  208. +>int u_array_src[20] = { 0 };    /* complete its type */
  209. +
  210. +Hmm, we agree that GCC failed to conform this time...
  211.  
  212. Good.
  213.  
  214. +>-----------------------------------------------------------------------------
  215. +>#12)  GCC fails to issue errors for the following invalid C code involving
  216. +>      the binary `-' operator, even when the -pedantic-errors option is used.
  217. +[Declarations similar to #11.]
  218. +>  i = & u_array_src - & b_array_src;            /* ERROR */
  219. +
  220. +... Again, we agree that GCC failed to conform.
  221.  
  222. Good.
  223.  
  224. +>-----------------------------------------------------------------------------
  225. +>#13)  GCC fails to issue errors for the following invalid C code involving
  226. +>      invalid null pointer constants, even when the -pedantic-errors option
  227. +>int (*fp) ();
  228. +>void test () { fp = (void *) (void *) 0; }    /* ERROR */
  229. +
  230. +... we agree that GCC failed.
  231.  
  232. Good.
  233.  
  234. +>-----------------------------------------------------------------------------
  235. +>#14)  GCC [-pedantic-errors] fails to issue errors for the following invalid
  236. +[Declarations deleted but all had pointer types, i.e. all scalars -- N.D.]
  237. +>  p_to_func_value = (p_to_func_type) p_to_object_value;         /* ERROR */
  238. +>  p_to_func_value = (p_to_func_type) p_to_incomp1_value;        /* ERROR */
  239. +>  p_to_func_value = (p_to_func_type) p_to_incomp2_value;        /* ERROR */
  240. +
  241. +I see no violation of a constraint.
  242.  
  243. Quite so.  This was a mistake on my part.  The behavior is undefined for
  244. this case, and I'm moving the test file to my "undefined behavior" pile.
  245.  
  246. +>-----------------------------------------------------------------------------
  247. +>#15)  GCC [-pedantic-errors] fails to issue errors for the following invalid
  248. +[Declarations deleted but all had pointer types, i.e. all scalars -- N.D.]
  249. +>  p_to_object_value = (p_to_object_type) p_to_func_value;       /* ERROR */
  250. +>  p_to_incomp1_value = (p_to_incomp1_type) p_to_func_value;     /* ERROR */
  251. +>  p_to_incomp2_value = (p_to_incomp2_type) p_to_func_value;     /* ERROR */
  252. +
  253. +Ditto.  [s/function call/arithmetic/.]
  254.  
  255. Quite so.  This was a mistake on my part.  The behavior is undefined for
  256. this case, and I'm moving the test file to my "undefined behavior" pile.
  257.  
  258. +>-----------------------------------------------------------------------------
  259. +>#16)  GCC [-pedantic-errors] fails to issue errors for the following invalid
  260. +>static int object_decl_6;
  261. +>static int object_defn_6 = 0;
  262. +>void test () {
  263. +>    extern double object_decl_6;                /* ERROR */
  264. +>    extern double object_defn_6;                /* ERROR */
  265. +>}
  266. +
  267. +As in #1, I see no violation of a constraint.  The behavior is undefined but
  268. +silence is allowed.
  269.  
  270. Agreed.  I have moved this test case to my "undefined behavior" pile.
  271.  
  272. +>-----------------------------------------------------------------------------
  273. +>#17)  GCC [-pedantic-errors] fails to issue errors for the following invalid
  274. +>void callee (char c);
  275. +>void foobar () { void callee(); }     /* ERROR */
  276. +>void callee (char c) { }
  277. +
  278. +Ditto.
  279.  
  280. Agreed.  I have moved this test case to my "undefined behavior" pile.
  281.  
  282. +>-----------------------------------------------------------------------------
  283. +>#18)  GCC incorrectly issues an error for the following standard-conformant
  284. +>      ANSI C code when the -pedantic-errors option is used.
  285. +>extern const int func_1 ();
  286. +
  287. +Spurious diagnostics are allowed...
  288.  
  289. Quite so.  This is another "quality of implementation" issue.
  290.  
  291. +>-----------------------------------------------------------------------------
  292. +>#19)  GCC fails to issue an error for the following pair of incompatible
  293. +>      function declarations, even when the -pedantic-errors option is used.
  294. +>extern const int func_4 ();
  295. +>extern int func_4 ();                   /* ERROR */
  296. +
  297. +For the fourth time, this does not violate a constraint.
  298.  
  299. In this case Norman, you are wrong.  This violates the third constraint
  300. listed in section 3.5.
  301.  
  302. +>-----------------------------------------------------------------------------
  303. +>#20)  GCC incorrectly issues errors for the following standard-conformant
  304. +>      ANSI C code when the -pedantic-errors option is used.
  305. +>static enum E1 { red, green, blue};
  306. +>static struct S1 { int member; };
  307. +>static union U2 { int member; };
  308. +>void foobar () {
  309. +>    auto enum E2 { red, green, blue };
  310. +>    auto struct S2 { int member; };
  311. +>    auto union U2 { int member; };
  312. +>}
  313. +
  314. +Spurious diagnostics are allowed...
  315.  
  316. Agreed.  This is another "quality of implementation" issue.
  317.  
  318.  
  319. // Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
  320. //
  321. //      "On the one hand I knew that programs could have a compelling
  322. //       and deep logical beauty, on the other hand I was forced to
  323. //       admit that most programs are presented in a way fit for
  324. //       mechanical execution, but even if of any beauty at all,
  325. //       totally unfit for human appreciation."
  326. //                                              -- Edsger W. Dijkstra
  327. -- 
  328.  
  329. // Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
  330. //
  331. //      "On the one hand I knew that programs could have a compelling
  332. //       and deep logical beauty, on the other hand I was forced to
  333. //       admit that most programs are presented in a way fit for
  334. //       mechanical execution, but even if of any beauty at all,
  335. //       totally unfit for human appreciation."
  336. //                                              -- Edsger W. Dijkstra
  337.