![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to msgbox CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10no / cmd / cfront / ooptcfront|
Return to msgbox CVS log | Up to [Research Unix] / researchv10no / cmd / cfront / ooptcfront |
1.1 root 1: &&&&
2: Return-Path: <[email protected]>
3: Received: from indirect.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
4: id AA08711; Tue, 16 May 89 09:31:32 EDT
5: Received: by indirect.odi.com (4.0/SMI-4.0/ODI-C2)
6: id AA17362; Tue, 16 May 89 09:31:48 EDT
7: Message-Id: <[email protected]>
8: To: c++-bugs
9: Subject: void return types and void * types as printed into C
10: Date: Tue, 16 May 89 09:31:47 EDT
11: From: Benson I. Margulies <[email protected]>
12:
13: Pretty much all C compilers these days support void. Sun's certainly does.
14: The mapping of void to char in cfront makes some debuggers print junk.
15: &&&&
16: &&&&
17: Return-Path: <[email protected]>
18: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
19: id AA08826; Tue, 16 May 89 10:33:10 EDT
20: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
21: id AA02086; Tue, 16 May 89 10:33:14 EDT
22: Date: Tue, 16 May 89 10:33:14 EDT
23: From: [email protected]
24: Message-Id: <[email protected]>
25: To: c++-bugs
26: Subject: lexer is confused during :: processing
27:
28:
29: The following is a bug report that will be forwarded to AT&T. It is in a
30: template form designed by AT&T to help them speed up the disposition of bug
31: reports; you may feel inclined to dispute this claim.
32:
33:
34:
35:
36:
37: who: [email protected]
38: file:
39: date: 5/12/89
40: state: not fixed
41: sum:
42:
43: A reference at top level to a member of the form x::y provokes an error
44: message if y also happens to be the name of a class with a constructor.
45:
46:
47: release filed under: beta 6
48: MR:
49: priority:
50: category:
51: teststate:
52: name of changed files:
53: release agent:
54: related MRs:
55: description of bug with output now and expected output:
56:
57:
58: Output:
59:
60: CC -I/usr1/sam/2.0/test/ +e0 -F /tmp/lalex-bug.C -c > /dev/null
61: "/usr1/sam/2.0/test/lalex-bug.C", line 23: error: foo redefined: both a class name with constructor and an identifier
62: "/usr1/sam/2.0/test/lalex-bug.C", line 25: error: foo1 redefined: both a class name with constructor and an identifier
63:
64: Compilation exited abnormally with code 1 at Mon May 15 19:06:18
65:
66:
67:
68: Expected Output:
69:
70: The test should compile without any error messages.
71:
72:
73: description of analysis and changes:
74:
75: The problem appears to be localized to the lexer's ability to deal with names
76: of the form x::y at the top level, when y also happens to be the name of a
77: class. It does does not account for the fact that y is in the scope of x and
78: is consequently not a top level definition.
79:
80:
81:
82: Example below if available-
83: */
84:
85: /* test exhibiting bug goes below */
86:
87: class foo {
88: foo() ;
89: } ;
90:
91: class foo1 {
92: foo1() ;
93: } ;
94:
95: class bar {
96: public:
97: static int foo1 ;
98: void foo() ;
99: } ;
100:
101: class bar1 {
102: public:
103: void foo() {} ; // No problem with foo being an inline
104: } ;
105:
106:
107:
108: void bar::foo() {} // Redefinition error for foo
109:
110: int bar::foo1 = 0 ; // Similar redefinition error
111:
112: main () {
113: bar::foo1 = 5 ; // This is ok
114: }
115: &&&&
116: &&&&
117: Return-Path: <[email protected]>
118: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
119: id AA08913; Tue, 16 May 89 10:43:55 EDT
120: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
121: id AA02104; Tue, 16 May 89 10:44:00 EDT
122: Date: Tue, 16 May 89 10:44:00 EDT
123: From: [email protected]
124: Message-Id: <[email protected]>
125: To: c++-bugs
126: Subject: typedef enum foo{} ; core dumps
127:
128:
129: This is a bug report that will be submitted to AT&T. It has been fixed at ODI.
130:
131:
132:
133: /*ident "@(#)ctrans:bug.header 1.1" */
134: /*
135: who: [email protected]
136: file:
137: date: 5/15/89
138: state: not fixed
139: sum:
140:
141: An enumeration typedef of the form:
142:
143: typedef bool {true, false} bool ;
144:
145: provokes a core dump.
146:
147:
148: release filed under: beta 6
149: MR:
150: priority:
151: category:
152: teststate:
153: name of changed files:
154: release agent:
155: related MRs:
156: description of bug with output now and expected output:
157:
158: The core dump is due to a null pointer being dereferenced at line 454 in the
159: function:
160: bit type::check(Ptype t, TOK oper)
161:
162: The backtrace is:
163:
164: #0 0x41b42 in check__4typeFP4typeUc (__0this=(Ptype) 0x76594, __0t=(Ptype) 0x765d8, __0oper=0) (typ.c line 454)
165: #1 0x2b820 in hide__4nameFv (__0this=(Pname) 0x6db6a) (norm.c line 579)
166: #2 0x2b1bc in aggr__8basetypeFv (__0this=(Pbase) 0x76594) (norm.c line 415)
167: #3 0x447cc in yyparse__Fv () (gram.y line 652)
168: #4 0x43b86 in syn__Fv () (gram.y line 253)
169: #5 0x294e4 in run__Fv () (main.c line 83)
170: #6 0x2a264 in main (__0argc=1, __0argv=(char **) 0xefffe68) (main.c line 477)
171:
172:
173: OUTPUT:
174:
175: CC temp.C:
176: "temp.C", line 2: internal <<C++ Translator 2.0 Beta 6 04/12/89>> error: bus error (or something nasty like that)
177: 1 error
178:
179:
180: The test should have compiled without any errors.
181:
182: description of analysis and changes:
183:
184: The error appears to be due to check for EOBJ in the following code fragment:
185:
186: b1 = t1->base;
187: switch (b1) {
188: case TYPE:
189: if (Pbase(t1)->b_const) cnst1++;
190: t1 = Pbase(t1)->b_name->tp;
191: goto top;
192: * case EOBJ:
193: * t1 = Penum(Pbase(t1)->b_name->tp)->e_type;
194: * goto top;
195: }
196:
197: b2 = t2->base;
198: switch (b2) {
199: case TYPE:
200: if (Pbase(t2)->b_const) cnst2++;
201: t2 = Pbase(t2)->b_name->tp;
202: goto top;
203: * case EOBJ:
204: * t2 = Penum(Pbase(t2)->b_name->tp)->e_type;
205: * goto top;
206: }
207:
208: The "goto top" statement bypasses the check for null pointers that guards the
209: enclosing while loop.
210:
211: There seem to be two possible fixes:
212:
213: 1) Change the goto top into a continue, so that the while expression is
214: evaluated. This provokes a redefinition error message, which may be the
215: correct thing to do, but the Reference manual is unclear on this point. The
216: Evolution of C++:1985 to 1989 paper seems to favor the notion of separate name
217: spaces for structure tags, and possibly for enum tags. The second fix is in
218: keeping with this trend.
219:
220:
221: 2) The second alternative is to permit such a declaration. The EOBJ case
222: blocks the processing of EOBJ types later in the body of the same function, at
223: the enum_check label. Removing the lines marked with asterisks, permits
224: control to reach the enum_check code, and consequently permit such
225: declarations.
226:
227: Example below if available-
228: */
229:
230: /* test exhibiting bug goes below */
231:
232:
233:
234: typedef enum bool {true, false} bool ;
235: &&&&
236: &&&&
237: Return-Path: <[email protected]>
238: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
239: id AA09075; Tue, 16 May 89 11:22:14 EDT
240: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
241: id AA02122; Tue, 16 May 89 11:22:18 EDT
242: Date: Tue, 16 May 89 11:22:18 EDT
243: From: [email protected]
244: Message-Id: <[email protected]>
245: To: c++-bugs
246: Subject: BD in patch step
247:
248:
249: Another candidate for AT&T.
250:
251:
252: /*ident "@(#)ctrans:bug.header 1.1" */
253: /*
254: who: [email protected]
255: file:
256: date: ?/?/89
257: state: not fixed
258: sum:
259:
260:
261: The patch step, ie. the step following the link step to ensure that constructors
262: are run on static varaibles, takes a very long time when the a.out file
263: contains debug symbols. "patching" cfront takes approximately 4 minutes on a
264: Sun 3/60.
265:
266: The enclosed fix speeds up the "patch step", it reduces the time taken to
267: patch "cfront" to approximately 5 seconds.
268:
269: release filed under: beta 6
270: MR:
271: priority:
272: category:
273: teststate:
274: name of changed files:
275: release agent:
276: related MRs:
277: description of bug with output now and expected output:
278:
279:
280:
281: compile (with the -g option) and link cfront or any substantial C++ program
282: and observe the time taken by the patch step.
283:
284:
285: description of analysis and changes:
286:
287:
288:
289: The excessive time was due to the random i/o being done to obtain the string
290: for every symbol in a.out file. The enclosed fix uses a faster test that
291: eliminates the random i/o associated with debug symbols.
292:
293:
294:
295: The diff for BSDpatch.c is enclosed below:
296:
297:
298: diff patch.c /odi/C++/install/att_2_0b6/Patch/BSDpatch.c
299: 106,110d104
300: <
301: <
302: < /* a symbol table entry, ignore it */
303: < if (sym.n_type & (unsigned char) N_STAB) continue ;
304: <
305:
306:
307:
308: Example below if available-
309:
310:
311: Use cfront as a candidate.
312:
313:
314: */
315:
316: /* test exhibiting bug goes below */
317:
318:
319: &&&&
320: &&&&
321: Return-Path: <[email protected]>
322: Received: from valens.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
323: id AA10875; Tue, 16 May 89 17:21:34 EDT
324: Received: by valens.odi.com (4.0/SMI-4.0/ODI-C2)
325: id AA03492; Tue, 16 May 89 17:21:52 EDT
326: Date: Tue, 16 May 89 17:21:52 EDT
327: From: [email protected]
328: Message-Id: <[email protected]>
329: To: c++-bugs
330: Subject: Overloading the new operator
331:
332: If you provide an overloaded "operator new" with extra arguments, and
333: do not provide an "operator new" with no extra arguments, you get an
334: incomprehensible error message, whose line number is the last line of
335: the constructor function. I don't think it should be an error at all.
336:
337: &&&&
338: &&&&
339: Return-Path: <[email protected]>
340: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
341: id AA13763; Wed, 17 May 89 17:55:45 EDT
342: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
343: id AA04487; Wed, 17 May 89 17:55:51 EDT
344: Date: Wed, 17 May 89 17:55:51 EDT
345: From: [email protected]
346: Message-Id: <[email protected]>
347: To: c++-bugs
348: Subject: data members of the form "struct x {} x;" are broken
349:
350:
351: /*ident "@(#)ctrans:bug.header 1.1" */
352: /*
353: who: [email protected]
354: file:
355: date: 5/17/89
356: state: not fixed
357: sum:
358:
359: Data members of the form:
360:
361: struct x {} x ;
362:
363: are incorrectly translated. They are omitted completely from the C struct
364: generated as a translation of the enclosing class.
365:
366: release filed under: beta 6
367: MR:
368: priority:
369: category:
370: teststate:
371: name of changed files:
372: release agent:
373: related MRs:
374: description of bug with output now and expected output:
375:
376:
377: Consider a class declaration of the form:
378:
379: class s {
380: class x1 {
381: int i ;
382: } x1; // Does not emit this field in the generated c struct
383: };
384:
385: Class s is translated by cfront into:
386:
387: #line 1 "2.0/test/struct-bug.c"
388: struct s { /* sizeof s == 4 */
389: };
390:
391: Note the missing reference to the field x1.
392:
393: The correct translation after applying the enclosed fix is:
394:
395: #line 1 "struct-bug.c"
396: struct s { /* sizeof s == 4 */
397:
398: #line 4 "struct-bug.c"
399: struct x1 x1__1s ;
400: };
401:
402:
403:
404: description of analysis and changes:
405:
406: The problem is that the type name x1, hides the member name x1, in the member
407: table for the class "s". The function classdef::print_members does not allow
408: for such hiding. The fix provided below accounts for this hiding.
409:
410: 1374,1378c1371,1372
411: < // Sam: A class or an enum type declared within a class can hide a
412: < // member with the same name, so make sure that it gets printed by
413: < // traversing the n_tbl_list to get at these names.
414: < for (Pname nn=memtbl->get_mem(i=1); nn; nn=memtbl->get_mem(++i))
415: < do if (nn->base==NAME
416: ---
417: > for (Pname nn=memtbl->get_mem(i=1); nn; nn=memtbl->get_mem(++i)) {
418: > if (nn->base==NAME
419: 1389,1392c1383,1384
420: < }
421: < while ((nn->base == NAME) &&
422: < ((nn->tp->base!=CLASS) || (nn->tp->base!=ENUM)) &&
423: < (nn = nn->n_tbl_list)) ;
424: ---
425: > }
426: > }
427:
428:
429:
430:
431: Example below if available-
432: */
433:
434: /* test exhibiting bug goes below */
435:
436:
437: class s {
438: class x1 {
439: int i ;
440: } x1; // Does not emit this field in the generated c struct
441: };
442:
443: s v ;
444: &&&&
445: &&&&
446: Return-Path: <[email protected]>
447: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
448: id AA15049; Thu, 18 May 89 10:44:36 EDT
449: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
450: id AA04745; Thu, 18 May 89 10:44:41 EDT
451: Date: Thu, 18 May 89 10:44:41 EDT
452: From: [email protected]
453: Message-Id: <[email protected]>
454: To: c++-bugs
455: Subject: linkage specification is incorrectly processed
456:
457:
458:
459:
460:
461: /*ident "@(#)ctrans:bug.header 1.1" */
462: /*
463: who: [email protected]
464: file:
465: date: 5/18/89
466: state: not fixed
467: sum:
468:
469: The linkage specification sometimes produces unwarranted error messages.
470:
471: release filed under: beta 6
472: MR:
473: priority:
474: category:
475: teststate:
476: name of changed files:
477: release agent:
478: related MRs:
479: description of bug with output now and expected output:
480:
481: Compiling the program below provokes an error message when it shouldn't
482:
483: CC 2.0/test/linkage-bug.C:
484: "2.0/test/linkage-bug.C", line 6: error: inconsistent linkage specifications for malloc()
485: 1 error
486:
487:
488: description of analysis and changes:
489:
490:
491: The test to determine whether two linkages are consistent is incorrect in the
492: function
493:
494: Pname name::dofct(Ptable tbl, TOK scope)
495:
496: The fix is provided below as output from diff:
497:
498: file: dcl3.c
499: 1667,1669c1667
500: < if (linkage && nf->f_signature &&
501: < *nf->f_signature // the signature is not ""
502: < )
503: ---
504: > if (linkage && nf->f_signature)
505:
506:
507: Example below if available-
508: */
509:
510: /* test exhibiting bug goes below */
511:
512:
513:
514: extern "C" char *malloc(unsigned);
515:
516: extern "C" {
517: char *malloc(unsigned);
518:
519: } ;
520: &&&&
521: &&&&
522: Return-Path: <[email protected]>
523: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
524: id AA17783; Fri, 19 May 89 10:45:39 EDT
525: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
526: id AA05539; Fri, 19 May 89 10:45:47 EDT
527: Date: Fri, 19 May 89 10:45:47 EDT
528: From: [email protected]
529: Message-Id: <[email protected]>
530: To: c++-bugs
531: Cc: benson
532: Subject: A missing ";" after a function declaration provokes a core dump
533:
534:
535:
536: /*ident "@(#)ctrans:bug.header 1.1" */
537: /*
538: who: [email protected]
539: file:
540: date: 5/19/89
541: state: not fixed
542: sum:
543:
544: A missing semi colon after a function declaration causes a core dump.
545:
546: release filed under: beta 6
547: MR:
548: priority:
549: category:
550: teststate:
551: name of changed files:
552: release agent:
553: related MRs:
554: description of bug with output now and expected output:
555:
556: A missing semi after a function declaration is detected as an error, but the
557: cfront core dumps trying to issue the error message since the format effector
558: used for the error message is a %t(for type) rather than a %k for token.
559:
560: Erroneous Output
561: ----------------
562:
563: CC 2.0/test/syntax-bug.c:
564: "2.0/test/syntax-bug.c", line 2: error: syntax error: unexpected "2.0/test/syntax-bug.c", line 2: "2.0/test/syntax-bug.c", line 2: internal <<C++ Translator 2.0 Beta 6 04/12/89>> error: bus error (or something nasty like that)
565: 1 error
566:
567:
568: Correct Output
569: -------------
570:
571: CC syntax-bug.c:
572: "syntax-bug.c", line 2: error: syntax error: unexpected char
573: "syntax-bug.c", line 2: error: syntax error
574:
575:
576: description of analysis and changes:
577:
578: Fixing the call to error in the production (in file gram.y)
579:
580: arg_list : arg_lp arg_type_list ellipsis_opt RP TYPE
581:
582: to use the %k format effector fixes the problem.
583:
584:
585: Example below if available-
586: */
587:
588: /* test exhibiting bug goes below */
589:
590:
591:
592: int foo(int i)
593:
594: char i ;
595: &&&&
596: &&&&
597: Return-Path: <[email protected]>
598: Received: from valens.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
599: id AA06592; Wed, 24 May 89 17:49:46 EDT
600: Received: by valens.odi.com (4.0/SMI-4.0/ODI-C2)
601: id AA01476; Wed, 24 May 89 17:49:36 EDT
602: Date: Wed, 24 May 89 17:49:36 EDT
603: From: [email protected]
604: Message-Id: <[email protected]>
605: To: c++bugs
606: Subject: socketpair
607: Reply-To: [email protected]
608:
609: The BSD system call "socketpair" is not defined in any of the
610: include files.
611:
612: &&&&
613: &&&&
614: Return-Path: <[email protected]>
615: Received: from valens.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
616: id AA08331; Thu, 25 May 89 11:12:25 EDT
617: Received: by valens.odi.com (4.0/SMI-4.0/ODI-C2)
618: id AA02117; Thu, 25 May 89 11:12:17 EDT
619: Date: Thu, 25 May 89 11:12:17 EDT
620: From: [email protected]
621: Message-Id: <[email protected]>
622: To: c++bugs
623: Subject: more standard declarations
624: Reply-To: [email protected]
625:
626: C++'s libc.h does declare mktemp, but does not have a declaration
627: for mkstemp. These are both library routines from the "(3)" part
628: of the documentation.
629: &&&&
630: &&&&
631: Return-Path: <[email protected]>
632: Received: from moon.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
633: id AA04276; Tue, 20 Jun 89 12:34:12 EDT
634: Received: by moon.odi.com (4.0/SMI-4.0/ODI-C2)
635: id AA00792; Tue, 20 Jun 89 12:34:12 EDT
636: Date: Tue, 20 Jun 89 12:34:12 EDT
637: From: [email protected]
638: Message-Id: <[email protected]>
639: To: c++-bugs
640: Subject: anonymous union bug
641:
642:
643:
644: /*ident "@(#)ctrans:bug.header 1.1" */
645: /*
646:
647: who: Rick Tompkins, Object Design, Inc.
648:
649: file: print2.c:658
650:
651: default:
652: // encode with lexicallevel UNLESS ``special''
653: // e.g. __builtin
654: if (string[0]!='_' || string[1]!='_') {
655: if (i)
656: 658: fprintf(out_file,"__%d__O%d.",lex_level-1,i,i);
657: else
658: fprintf(out_file,"__%d",lex_level);
659: }
660: }
661: break;
662:
663:
664: date: 6/20/89
665:
666: state: not fixed
667:
668: sum: Anonymous unions within functions result in undefined unions.
669:
670: release filed under: beta 6
671:
672: MR:
673: priority:
674: category:
675: teststate:
676: name of changed files:
677: release agent:
678: related MRs:
679:
680: description of bug with output now and expected output:
681:
682: Anonymous unions within functions result in undefined unions.
683: This is due to the inconsistency in outputing the lexical level
684: of such a union when generating its C name. In an expression the
685: union name generated for a anonymous union at the function level
686: has the lexical level part while the corresponding declaration
687: does not.
688:
689: EXAMPLE:
690:
691: main ()
692: {
693:
694: union {
695: char u_c;
696: int u_i;
697: float u_f;
698: };
699:
700: u_c = 'a'; /* These result in an undefined union name. */
701: u_i = 9;
702: u_f = 3.5;
703:
704: }
705:
706:
707: OUTPUT:
708:
709: #line 1 "e.out.C"
710:
711: /* <<C++ Translator 2.0 Beta 6 04/12/89 ODI version 1.2.1.18 of 89/06/06 16:24:40 by benson. Compiled by tompkins at 89-06-08 14:48:22 in /usr1/tompkins/C++_2.0_bugs/src>> */
712: /* < e.out.C > */
713:
714: #line 3 "e.out.C"
715: char *_vec_new ();
716:
717: #line 3 "e.out.C"
718: char _vec_delete ();
719: typedef int (*__vptp)();
720: struct __mptr {short d; short i; __vptp f; };
721:
722: #line 3 "e.out.C"
723:
724: #line 6 "e.out.C"
725: union __C1 { /* sizeof __C1 == 4 */
726:
727: #line 7 "e.out.C"
728: char u_c ;
729: int u_i ;
730: float u_f ;
731: };
732:
733: #line 3 "e.out.C"
734: int main (){ _main();
735: #line 4 "e.out.C"
736: {
737: #line 6 "e.out.C"
738:
739: #line 10 "e.out.C"
740: union __C1 __O1 ; /* Declaration of generated union. */
741:
742: #line 12 "e.out.C"
743: __1__O1.u_c = 'a' ; /* Use of generated union has different name.*/
744: __1__O1.u_i = 9 ;
745: __1__O1.u_f = 3.5 ;
746: }
747: }
748: #line 18 "e.out.C"
749:
750: /* the end */
751:
752: ERRORS:
753:
754: moon:tompkins(34)> /usr/local/bin/CC -g -o e.out e.out.C
755: e.out.C:
756: cc -o e.out -g e.out..c -l/usr/local/lib/libC.1.2.a
757: "e.out.C", line 12: __1__O1 undefined
758:
759:
760: description of analysis and changes:
761:
762: The simplest change is to delete the lexical level part of the
763: generated union name. And of course, the extra "i" argument to
764: fprintf can be deleted as well. Given that any generated union
765: name is guaranteed to be unique within a file, the lexical level
766: isn't needed.
767:
768:
769: print2.c:658> fprintf(out_file,"__O%d.",,i);
770:
771:
772: Example below if available-
773: */
774:
775: /* test exhibiting bug goes below */
776:
777:
778: &&&&
779: &&&&
780: Return-Path: <[email protected]>
781: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
782: id AA14961; Wed, 28 Jun 89 19:35:57 EDT
783: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
784: id AA07403; Wed, 28 Jun 89 19:35:58 EDT
785: Date: Wed, 28 Jun 89 19:35:58 EDT
786: From: [email protected]
787: Message-Id: <[email protected]>
788: To: c++-bugs
789: Subject: name hiding lossage in real 2.0
790:
791:
792:
793: Rather than fixing the bugs associated with conflicting type and member names,
794: 2.0 has made things worse. You now have to ensure that even formal parmeter
795: member names don't conflict with an existing type.
796:
797: Thus the following example that compiled under 2.0 beta, fails in the real 2.0
798: Changing the name of the formal for y::foo permits compilation to proceed.
799:
800:
801:
802: class x{ public: x() ;} ;
803:
804: class y {
805: foo (int x ) ;
806: gotcha() ;
807: } ;
808:
809: y::gotcha() {
810: new x() ; // Syntax error in real 2.0, ok in beta 2.0
811: }
812: &&&&
813: &&&&
814: Return-Path: <benson>
815: Received: by odi.com (4.0/SMI-4.0/ODI-4)
816: id AA28498; Sun, 2 Jul 89 08:02:50 EDT
817: Date: Sun, 2 Jul 89 08:02:50 EDT
818: From: Benson Margulies <benson>
819: Message-Id: <[email protected]>
820: To: c++bugs
821: Subject: exit.c shadows important functionality of sun's exit(3)
822:
823: exit(3) has various responsabilities other than calling _exit.
824: The copy of exit in libC.a busts profiling, in that the call
825: to _mcount is lost. It probably also busts sun's on_exit
826: stuff, and possibly other things.
827: &&&&
828: &&&&
829: Return-Path: <benson>
830: Received: by odi.com (4.0/SMI-4.0/ODI-4)
831: id AA02052; Mon, 3 Jul 89 20:07:23 EDT
832: Message-Id: <[email protected]>
833: To: [email protected]
834: Cc: c++-bugs
835: Subject: Re: stdargs.h
836: In-Reply-To: Your message of Mon, 03 Jul 89 17:22:21 -0400.
837: <[email protected]>
838: Date: Mon, 03 Jul 89 20:07:22 EDT
839: From: Benson I. Margulies <benson>
840:
841:
842: The file /odi/C++/install/bugs/include/stdargs.h is missing an #endif.
843:
844: (The att2.0 version of the file is also broken.)
845:
846: stdargs.h is full of non-working code. stdarg.h is correct.
847: stdargs.h should be deleted.
848:
849: &&&&
850: &&&&
851: Return-Path: <[email protected]>
852: Received: from moon.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
853: id AA07601; Wed, 12 Jul 89 15:54:48 EDT
854: Received: by moon.odi.com (4.0/SMI-4.0/ODI-C2)
855: id AA03177; Wed, 12 Jul 89 15:55:19 EDT
856: Date: Wed, 12 Jul 89 15:55:19 EDT
857: From: [email protected]
858: Message-Id: <[email protected]>
859: To: c++-bugs
860: Subject: [aml: trivial spelling bug]
861:
862: Return-Path: <aml>
863: Date: Wed, 12 Jul 89 15:32:51 EDT
864: From: Al Leisinger <aml>
865: To: rick
866: Subject: trivial spelling bug
867:
868: Cfront error message:
869: warning: negative retured from function returning unsigned
870: ^^^^^^^
871: returned ??
872: I know it's trivial but why not report it ?
873:
874: &&&&
875: &&&&
876: Return-Path: <[email protected]>
877: Received: from valens.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
878: id AA09657; Wed, 12 Jul 89 18:50:48 EDT
879: Received: by valens.odi.com (4.0/SMI-4.0/ODI-C2)
880: id AA16557; Wed, 12 Jul 89 18:51:05 EDT
881: Date: Wed, 12 Jul 89 18:51:05 EDT
882: From: [email protected]
883: Message-Id: <[email protected]>
884: To: c++bugs
885: Subject: mman.h
886: Reply-To: [email protected]
887:
888: mman.h has been changed from the beta release to the 2.0 release. It
889: now no longer provides a declaration for the "mprotect" system call.
890:
891: &&&&
892: &&&&
893: Return-Path: <[email protected]>
894: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
895: id AA02846; Fri, 14 Jul 89 08:35:48 EDT
896: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
897: id AA00287; Fri, 14 Jul 89 08:36:10 EDT
898: Message-Id: <[email protected]>
899: To: sam, c++bugs
900: Subject: void versus ansi mode
901: Date: Fri, 14 Jul 89 08:36:06 EDT
902: From: Benson I. Margulies <[email protected]>
903:
904: Cfront translates void types to char types, in apparent support
905: of really ancient K&R c compilers. This is supposedly turned off
906: by +a1. However,
907:
908: (1) the code in print2.c that conditions on ansi_opt fails to
909: print the string "void" when ansi mode is turned on. It just prints
910: nothing.
911:
912: (2) the code in simpl.c referred to by print2.c dosen't even check
913: ansi mode, it just emits a cast.
914:
915: I've changed print2 and simple to leave void be when running on a sun,
916: since the sun compiler is quite content with void. I also fixed it to
917: print "void" when in ansi mode.
918: &&&&
919: &&&&
920: Return-Path: <[email protected]>
921: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
922: id AA03158; Fri, 14 Jul 89 11:44:01 EDT
923: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
924: id AA00819; Fri, 14 Jul 89 11:44:00 EDT
925: Date: Fri, 14 Jul 89 11:44:00 EDT
926: From: [email protected]
927: Message-Id: <[email protected]>
928: To: c++-bugs
929: Subject: problem with reference initialization
930:
931:
932:
933: A reference initialized by a function returning a reference generates bad c
934: code which provokes an error message from cc of the form:
935:
936: "/usr1/sam/2.0/test/cast.C", line 3: unacceptable operand of &
937:
938:
939: for the example provided below:
940:
941:
942: int &foo () ;
943: int &i = foo() ;
944:
945:
946:
947: &&&&
948: &&&&
949: Return-Path: <[email protected]>
950: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
951: id AA17585; Wed, 19 Jul 89 07:46:52 EDT
952: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
953: id AA01219; Wed, 19 Jul 89 07:47:19 EDT
954: Message-Id: <[email protected]>
955: To: c++bugs
956: Subject: confusion over placement options
957: Date: Wed, 19 Jul 89 07:47:17 EDT
958: From: Benson I. Margulies <[email protected]>
959:
960: Please explain the following message:
961:
962: "foo.C", line 7: error: argument 2 of type void * expected for T::operator new()
963:
964: #include <sys/types.h>
965: #include <malloc.h>
966:
967: void * operator new (size_t, void *);
968:
969: class T {
970: public:
971: char * s;
972: void * operator new (size_t, void *);
973: T(int x, void * v) {
974: s = new (v)(char[x]);
975: };
976: };
977:
978: void * T::operator new (size_t s, void * v)
979: {
980: return (void *)malloc(s);
981: }
982:
983: T* Q()
984: {
985: int z = 1;
986: void * v = 0;
987: T* t = new (v)T(z, v);
988: return t;
989: }
990: &&&&
991: &&&&
992: Return-Path: <[email protected]>
993: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
994: id AA17849; Wed, 19 Jul 89 09:58:24 EDT
995: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
996: id AA01533; Wed, 19 Jul 89 09:58:52 EDT
997: Message-Id: <[email protected]>
998: To: c++bugs
999: Subject: don't put names on typedef param list params
1000: Date: Wed, 19 Jul 89 09:58:49 EDT
1001: From: Benson I. Margulies <[email protected]>
1002:
1003:
1004: The followings gets an entirely spurious error.
1005:
1006: class node {
1007: };
1008:
1009: typedef (* gruz) (node * node);
1010:
1011: class bn : public node {
1012: int y;
1013: };
1014:
1015: &&&&
1016: &&&&
1017: Return-Path: <[email protected]>
1018: Received: from pigpen.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1019: id AA18574; Wed, 19 Jul 89 12:39:44 EDT
1020: Received: by pigpen.odi.com (4.0/SMI-4.0/ODI-C2)
1021: id AA11032; Wed, 19 Jul 89 12:40:26 EDT
1022: Date: Wed, 19 Jul 89 12:40:26 EDT
1023: From: [email protected]
1024: Message-Id: <[email protected]>
1025: To: C++-bugs
1026: Subject: static members of nested classes
1027:
1028: Static members of nested class definitions don't work. The
1029: following code:
1030:
1031: main()
1032: {
1033: class T {
1034: public:
1035: static int count;
1036: };
1037:
1038: T::count++; // "int T::count;" also causes failure
1039: }
1040:
1041: results in a link error:
1042:
1043: ld: Undefined symbol
1044: T__main__Fv__L1::count
1045:
1046: Now, the C++ 2.0 reference manual says that
1047: (1) The declaration of a static member in its class declaration is
1048: NOT a definition.
1049: (2) Static members of a class declared local to some function ...
1050: cannot be initialized [and must therefore accept the default
1051: "all zeros" initialization].
1052:
1053: The current behavior, though, is worse than that: static members of a
1054: nested class cannot be referred to at all, because they are declared
1055: but never defined.
1056: &&&&
1057: &&&&
1058: Return-Path: <[email protected]>
1059: Received: from valens.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1060: id AA18753; Wed, 19 Jul 89 15:12:40 EDT
1061: Received: by valens.odi.com (4.0/SMI-4.0/ODI-C2)
1062: id AA24717; Wed, 19 Jul 89 15:13:09 EDT
1063: Date: Wed, 19 Jul 89 15:13:09 EDT
1064: From: [email protected]
1065: Message-Id: <[email protected]>
1066: To: [email protected]
1067: Cc: C++-bugs
1068: In-Reply-To: [email protected]'s message of Wed, 19 Jul 89 12:40:26 EDT <[email protected]>
1069: Subject: static members of nested classes
1070: Reply-To: [email protected]
1071:
1072: Date: Wed, 19 Jul 89 12:40:26 EDT
1073: From: [email protected]
1074:
1075: The current behavior, though, is worse than that: static members of a
1076: nested class cannot be referred to at all, because they are declared
1077: but never defined.
1078:
1079: You know, it's conceivable that this works properly with the C
1080: compiler that they use at AT&T, because C compilers are inconsistent
1081: about how they handle this. Harbison & Steele goes into great detail
1082: about the four different sets of behavior that they've seen in various
1083: C compilers.
1084:
1085: However, that's not much of an excuse, because if that's why the bug
1086: exists, then it's only because they are depending on non-ANSI-like
1087: behavior.
1088:
1089: &&&&
1090: &&&&
1091: Return-Path: <[email protected]>
1092: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1093: id AA26387; Fri, 21 Jul 89 08:57:51 EDT
1094: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
1095: id AA06686; Fri, 21 Jul 89 08:58:23 EDT
1096: Date: Fri, 21 Jul 89 08:58:23 EDT
1097: From: [email protected]
1098: Message-Id: <[email protected]>
1099: To: c++bugs
1100: Subject: malloc.h
1101:
1102: malloc.h is broken.
1103:
1104: First of all, the correct prototype for mallinfo on a sun is to
1105: take no arguments.
1106:
1107: Second of all, the attempt to deal with the identically named
1108: structure and function fails, since the function of no args
1109: gets C++ linkage.
1110:
1111: I kludged around it by removing the declaration from the extern "C",
1112: and surrounding the cc/malloc.h include with
1113:
1114: #pragma linkage C
1115: #pragma linkage
1116: &&&&
1117: &&&&
1118: Return-Path: <[email protected]>
1119: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1120: id AA06715; Thu, 27 Jul 89 11:51:19 EDT
1121: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
1122: id AA00607; Thu, 27 Jul 89 11:51:57 EDT
1123: Message-Id: <[email protected]>
1124: To: c++bugs
1125: Subject: local typedefs and references are broken
1126: Date: Thu, 27 Jul 89 11:51:54 EDT
1127: From: Benson I. Margulies <[email protected]>
1128:
1129:
1130: the following emits a reference to type "z" in the C code
1131: for the declaration of ZZ.
1132:
1133: int qq();
1134:
1135: int q(int a) {
1136: typedef int z;
1137: z Z;
1138: z& ZZ = Z;
1139:
1140: int b;
1141:
1142: Z = qq();
1143:
1144: b= (int)(a + ZZ);
1145:
1146: return b;
1147: }
1148: &&&&
1149: &&&&
1150: Return-Path: <[email protected]>
1151: Received: from pigpen.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1152: id AA07632; Thu, 27 Jul 89 18:22:56 EDT
1153: Received: by pigpen.odi.com (4.0/SMI-4.0/ODI-C2)
1154: id AA14970; Thu, 27 Jul 89 18:23:52 EDT
1155: Date: Thu, 27 Jul 89 18:23:52 EDT
1156: From: [email protected]
1157: Message-Id: <[email protected]>
1158: To: c++-bugs
1159: Subject: global ref variable init broken?
1160:
1161: The following file:
1162:
1163: int theint;
1164:
1165: int& intref(){return theint;};
1166: int& bar = intref();
1167:
1168: main()
1169: {
1170: }
1171:
1172: gives the message (from cc):
1173:
1174: "foo.C", line 4: unacceptable operand of &
1175:
1176: while
1177:
1178: int theint;
1179:
1180: int& intref(){return theint;};
1181: int bar = intref();
1182:
1183: main()
1184: {
1185: }
1186:
1187: and
1188:
1189: int theint;
1190:
1191: int& intref(){return theint;};
1192:
1193: main()
1194: {
1195: int& bar = intref();
1196: }
1197:
1198: both compile correctly.
1199: &&&&
1200: &&&&
1201: Return-Path: <[email protected]>
1202: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1203: id AA11374; Fri, 28 Jul 89 18:22:27 EDT
1204: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1205: id AA11900; Fri, 28 Jul 89 18:22:37 EDT
1206: Date: Fri, 28 Jul 89 18:22:37 EDT
1207: From: [email protected]
1208: Message-Id: <[email protected]>
1209: To: [email protected]
1210: In-Reply-To: [email protected]'s message of Fri, 28 Jul 89 15:13:15 EDT <[email protected]>
1211: Subject: initialization of local static variables
1212: Cc: c++bugs
1213:
1214: Date: Fri, 28 Jul 89 15:13:15 EDT
1215: From: [email protected]
1216:
1217: Are you aware of problems with the handling of static local variables?
1218: I created a static path object (which encapsulates a linked list)
1219: inside a function:
1220:
1221: person::person(string n, person* f, person* m)
1222: : name(n), age(-1), father(NULL), mother(NULL)
1223: {
1224: // Without cast to person*, cfront complains about "&this".
1225: set_father(f);
1226: set_mother(m);
1227: if (father)
1228: father->children.insert((person*) this);
1229: if (mother)
1230: mother->children.insert((person*) this);
1231:
1232: static path f_index = arrow(person, father);
1233: children.add_index(f_index);
1234: }
1235:
1236: The first time person::person runs, f_index is created, and temporary
1237: path_step objects (used to initialize permanent path_steps comprising
1238: the path) get deleted. I verified this by watching ~path_step run. On
1239: the second invocation of person::person, the path isn't created, but
1240: dtors are called anyway, sometimes with a zero address, sometimes not.
1241:
1242: If the f_index declaration is moved outside the function, so that it
1243: is static global, the program runs.
1244:
1245: I don't need a fix for this - I'm just wondering if I am
1246: misunderstanding something about when dtors should be run, or whether
1247: I'm running into a known bug.
1248:
1249:
1250: Jack
1251:
1252:
1253: (The code above is from /odi/aggs/src/person.C)
1254:
1255:
1256: The code generation for local static variables initialized with an expression
1257: that requires the use of compiler temporaries is busted. The constructor code
1258: for initializing the temporaries is run conditionally, since local static
1259: variables must be initialized just once, when control first passes through the
1260: declaration. Unfortunately, the destructor is run unconditionally in the
1261: generated code, each time control passes through the block containing the
1262: local static declaration.
1263:
1264: You may wish to avoid the use of local static variables with non-trivial
1265: initializations for now.
1266: &&&&
1267: &&&&
1268: Return-Path: <[email protected]>
1269: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1270: id AA20107; Wed, 2 Aug 89 13:11:40 EDT
1271: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
1272: id AA00545; Wed, 2 Aug 89 13:12:25 EDT
1273: Date: Wed, 2 Aug 89 13:12:25 EDT
1274: From: [email protected]
1275: Message-Id: <[email protected]>
1276: To: c++bugs
1277: Subject: complex initializations bungled for consts.
1278:
1279: when a complex expr initialization of a const is evaluated to an integer,
1280: dcl.c DEL's the variable init but neither zero's it nor skips the code
1281: that looks at it. Depending on accidents of storage, this can cause
1282: the compiler to core-dump shortly thereafter trying to run need_sti
1283: over it.
1284: &&&&
1285: &&&&
1286: Return-Path: <[email protected]>
1287: Received: from valens.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1288: id AA28108; Fri, 25 Aug 89 10:42:08 EDT
1289: Received: by valens.odi.com (4.0/SMI-4.0/ODI-C2)
1290: id AA04592; Fri, 25 Aug 89 10:42:08 EDT
1291: Date: Fri, 25 Aug 89 10:42:08 EDT
1292: From: [email protected]
1293: Message-Id: <[email protected]>
1294: To: c++-bugs
1295: Subject: Computed pointer-to-function values
1296: Reply-To: [email protected]
1297:
1298: In the following program, the last line, but only the last line, gets
1299: an error, namely "illegal indirection", whatever that means. I don't
1300: understand how the last line could not be legal C++ code.
1301:
1302: int
1303: twice(int x) {
1304: return x + x;
1305: }
1306:
1307: main() {
1308: int dummy;
1309: int (*fn)(int);
1310: int (*fn2)(int);
1311: int (*fn3)(int);
1312:
1313: fn = twice;
1314: fn2 = twice;
1315:
1316: dummy = (*fn)(30);
1317:
1318: dummy = fn(30);
1319:
1320: dummy = (fn)(3);
1321:
1322: fn3 = (dummy > 30 ? fn : fn2);
1323:
1324: dummy = (dummy > 30 ? fn : fn2)(30); /* line 22: illegal indirection */
1325:
1326: }
1327: &&&&
1328: &&&&
1329: Return-Path: <[email protected]>
1330: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1331: id AA28339; Fri, 25 Aug 89 11:30:08 EDT
1332: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
1333: id AA06818; Fri, 25 Aug 89 11:30:13 EDT
1334: Date: Fri, 25 Aug 89 11:30:13 EDT
1335: From: [email protected]
1336: Message-Id: <[email protected]>
1337: To: c++bugs, sam, stryker, tompkins
1338: Subject: Installation in /usr2/odi/c++/versions/odi2/src/
1339:
1340: Installation version odi2_34 in /usr2/odi/c++/versions/odi2/src/ at 89:7:25:11:26:44.
1341:
1342: Version odi2_34(1.34) from /usr1/benson/work/cfront/
1343:
1344: cfront croaked for
1345:
1346: class x : public y {
1347: public:
1348: x (a, b, c) : y(z(a), Cast(b)) {};
1349:
1350: because it tried to detect the entry to the initialization list
1351: only by seeing ) :, and to exit it at any ). So the close of the z(a)
1352: turned off the global that indicated that the current state was within
1353: a base init list, and then got confused by the cast. The fix is to use
1354: grammar actions to control the state.
1355:
1356:
1357: gram.y:
1358: revision 1.12
1359: date: 89/08/25 11:23:09; author: benson; state: Exp; lines added/del: 21/7
1360: set must_be_expr for base_init processing and for nothing else.
1361: Don't leave in_arg_list on in the base_init list.
1362:
1363: lalex.c:
1364: revision 1.6
1365: date: 89/08/25 11:22:33; author: benson; state: Exp; lines added/del: 20/18
1366: Remove code to try to set the must_be_expr code by detecting
1367: ) : and const : in the token stream. Depend on the grammar.
1368:
1369: &&&&
1370: &&&&
1371: Return-Path: <[email protected]>
1372: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1373: id AA04677; Tue, 29 Aug 89 12:31:06 EDT
1374: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1375: id AA02179; Tue, 29 Aug 89 12:31:03 EDT
1376: Date: Tue, 29 Aug 89 12:31:03 EDT
1377: From: [email protected]
1378: Message-Id: <[email protected]>
1379: To: c++-bugs
1380: Subject: missing error message
1381:
1382:
1383:
1384:
1385: The following example is in error, since the class "b" has effectively been
1386: defined twice in the global scope. Cfront fails to detect this error, and
1387: generates a bad translation that evokes complaints from the C compiler.
1388:
1389: Removing the member x::mb does result in an appropriate error message !
1390:
1391:
1392:
1393: class a {
1394: class b {
1395: int mb ;
1396: double r ;
1397: } cb ;
1398: } ;
1399:
1400:
1401:
1402: class x {
1403: int ma ; /* provokes the bug ? */
1404:
1405: class b {
1406: int mb ;
1407: } cb ;
1408: } ;
1409: &&&&
1410: &&&&
1411: Return-Path: <[email protected]>
1412: Received: from valens.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1413: id AA02798; Fri, 8 Sep 89 17:48:28 EDT
1414: Received: by valens.odi.com (4.0/SMI-4.0/ODI-C2)
1415: id AA05949; Fri, 8 Sep 89 17:51:07 EDT
1416: Date: Fri, 8 Sep 89 17:51:07 EDT
1417: From: [email protected]
1418: Message-Id: <[email protected]>
1419: To: c++-bugs
1420: Subject: base type expected for init_fn
1421: Reply-To: [email protected]
1422:
1423: Compiling the file /usr2/odi/storage/client/bug.C, I get the weird
1424: error message "base type expected for init_fn". Look at this file,
1425: and search for #define bug. If you remove this line, the file compiles.
1426: This is extremely strange since the thing that "bug" controls has
1427: nothing to do with the part of the code that causes the error message.
1428:
1429: valens:dlw(89)> pwd
1430: /usr2/odi/storage/client
1431: valens:dlw(90)> CC -v bug.C -o bug.o
1432: CC $Revision: 1.8 $ of $Date: 89/08/22 13:25:28 $ by $Author: tompkins $
1433: /lib/cpp -B -C -Dc_plusplus=1 -D__cplusplus=1 -DBSD -I/usr2/odi/C++/install/odi2/include bug.C > /usr/tmp/CC.5939/cpptmp
1434: /usr2/odi/C++/install/odi2/cfront +v +fbug.C </usr/tmp/CC.5939/cpptmp > /usr/tmp/CC.5939/bug.i
1435: <<C++ Translator 2.00 06/30/89 ODI version 1.42 of 89/09/07 15:05:58 by benson. Compiled by benson at 89-09-07 15:43:00 in /usr2/odi/C++/versions/odi2/src>>
1436: "bug.C", line 2916: error: base type expected for init_fn
1437: 1 error
1438: &&&&
1439: &&&&
1440: Return-Path: <[email protected]>
1441: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1442: id AA15018; Wed, 13 Sep 89 10:25:59 EDT
1443: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1444: id AA02436; Wed, 13 Sep 89 10:25:57 EDT
1445: Date: Wed, 13 Sep 89 10:25:57 EDT
1446: From: [email protected]
1447: Message-Id: <[email protected]>
1448: To: c++-bugs
1449: Subject: typedefs nested within a class definition
1450:
1451:
1452: Definition of a typedef nested within a class with the same name as a class
1453: definition, is not detected as an error, and may provoke subsequent confusing
1454: error messages, since the class definition is effectively blocked.
1455:
1456: An example:
1457:
1458:
1459: class t {double d ;} ;
1460:
1461: class c {
1462: typedef int t ; // Bug: this should be flagged as an error, but isn't.
1463: } ;
1464:
1465:
1466: // It appears that "t" is an int from this point forth !
1467: t i = 0 ;
1468: &&&&
1469: &&&&
1470: Return-Path: <[email protected]>
1471: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1472: id AA18635; Thu, 14 Sep 89 17:03:45 EDT
1473: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1474: id AA04200; Thu, 14 Sep 89 17:03:42 EDT
1475: Date: Thu, 14 Sep 89 17:03:42 EDT
1476: From: [email protected]
1477: Message-Id: <[email protected]>
1478: To: jack
1479: Cc: c++-bugs
1480: Subject: pure virtual operator functions are broken
1481:
1482:
1483: Compiling the following example:
1484:
1485: class c
1486: {
1487: virtual operator int() = 0 ;
1488: };
1489:
1490:
1491: provokes the internal error message:
1492:
1493: "/usr1/sam/2.0/test/z.C", line 5: internal /usr2/odi/C++/install/odi2/cfront error: signature of 0
1494:
1495:
1496: Cfront appears to be one field short; it uses name::n_initializer
1497: both to hold the type of the operator, however, the remarkable
1498: abstract class declaration syntax uses this field to store what looks
1499: like an initializer, thereby overwriting the operator type
1500: information.
1501:
1502: Just deserts for the abstract class kludge !
1503:
1504:
1505: Will save this one for the bugfest.
1506: &&&&
1507: &&&&
1508: Return-Path: <[email protected]>
1509: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1510: id AA14391; Tue, 19 Sep 89 18:21:56 EDT
1511: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1512: id AA11736; Tue, 19 Sep 89 18:21:54 EDT
1513: Date: Tue, 19 Sep 89 18:21:54 EDT
1514: From: [email protected]
1515: Message-Id: <[email protected]>
1516: To: c++-bugs, dlw
1517: Subject: name hiding lossage
1518:
1519:
1520:
1521: odi2_51 fixes the pernicious name hiding bug, where a formal argument name
1522: in a function member declaration would hide the name of an outer class
1523: definition, as in the example below:
1524:
1525:
1526:
1527: class x ;
1528:
1529: class c {
1530: foo(int x) ;
1531:
1532: bar(x *v) ; // invalid error message, x should be visible here
1533: } ;
1534:
1535: "hide.C", line 6: error: argument type expected for bar()
1536: &&&&
1537: &&&&
1538: Return-Path: <[email protected]>
1539: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1540: id AA28358; Tue, 26 Sep 89 10:08:38 EDT
1541: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
1542: id AA03843; Tue, 26 Sep 89 10:08:37 EDT
1543: Date: Tue, 26 Sep 89 10:08:37 EDT
1544: From: [email protected]
1545: Message-Id: <[email protected]>
1546: To: c++bugs
1547: Subject: static member functions treated like ordinary member functions
1548:
1549:
1550: class foo {
1551: public:
1552: static int x (int y) { return y; };
1553: int (*xx) (int);
1554: foo () { xx = x;};
1555: };
1556:
1557: foo FOO;
1558:
1559: compiling this gets:
1560:
1561: "bug.C", line 6: warning: address of bound function (try using ``foo ::*'' for po
1562: inter type and ``&foo ::x '' for address)
1563:
1564: which is wrong. Since x is a static function, it ought to be usuable
1565: like any other function.
1566: &&&&
1567: &&&&
1568: Return-Path: <[email protected]>
1569: Received: from pigpen.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1570: id AA14840; Wed, 4 Oct 89 13:19:17 EDT
1571: Received: by pigpen.odi.com (4.0/SMI-4.0/ODI-C2)
1572: id AA13854; Wed, 4 Oct 89 13:19:14 EDT
1573: Date: Wed, 4 Oct 89 13:19:14 EDT
1574: From: [email protected]
1575: Message-Id: <[email protected]>
1576: To: c++-bugs
1577: Subject: members of const objects not const
1578:
1579: The following incorrectly compiles without error. This bug is
1580: documented in the 2.0 release notes, page A-9.
1581:
1582: class embedded { public:
1583: int value;
1584: void update() {value++;};
1585: };
1586:
1587: class C { public:
1588: embedded strct;
1589: };
1590:
1591: main()
1592: {
1593: const C p;
1594: p.strct.update();
1595: p.strct.value = 23;
1596: }
1597: &&&&
1598: &&&&
1599: Return-Path: <[email protected]>
1600: Received: from mojo.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1601: id AA14856; Wed, 4 Oct 89 13:42:12 EDT
1602: Received: by mojo.odi.com (4.0/SMI-4.0/ODI-C2)
1603: id AA18996; Wed, 4 Oct 89 13:42:10 EDT
1604: Date: Wed, 4 Oct 89 13:42:10 EDT
1605: From: [email protected]
1606: Message-Id: <[email protected]>
1607: To: c++-bugs
1608: Subject: Can't Type Cast New Placement Arguments
1609:
1610:
1611: Compiling the following 3 lines provokes syntax errors for line 3.
1612:
1613: typedef unsigned int size_t;
1614: extern void * operator new(size_t,size_t,size_t);
1615: char *fund_01_xc_01 = new(size_t(1),size_t(2)) char('a');
1616: &&&&
1617: &&&&
1618: Return-Path: <[email protected]>
1619: Received: from pigpen.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1620: id AA15538; Wed, 4 Oct 89 16:49:48 EDT
1621: Received: by pigpen.odi.com (4.0/SMI-4.0/ODI-C2)
1622: id AA14895; Wed, 4 Oct 89 16:49:43 EDT
1623: Date: Wed, 4 Oct 89 16:49:43 EDT
1624: From: [email protected]
1625: Message-Id: <[email protected]>
1626: To: c++-bugs
1627: Subject: coercion ops order-dependent
1628:
1629: class test { public:
1630: void dummy() {};
1631: operator const test*() { return this; }; // the order of these ops ...
1632: operator test*() { return this; }; // ... is significant (??)
1633: };
1634:
1635: main()
1636: {
1637: test t;
1638: ((test*)t) -> dummy(); // both of these casts use operator test*()
1639: ((const test*)t) -> dummy(); // rather than operator const test*()
1640: };
1641:
1642: // however, if the ops appear in the opposite order in the class defn,
1643: // then they are called correctly --
1644: // BUT it is only a warning (not an error) that a const test* is used
1645: // as the this for the non-const member function dummy()
1646: &&&&
1647: &&&&
1648: Return-Path: <[email protected]>
1649: Received: from pigpen.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1650: id AA18054; Thu, 5 Oct 89 16:36:38 EDT
1651: Received: by pigpen.odi.com (4.0/SMI-4.0/ODI-C2)
1652: id AA16379; Thu, 5 Oct 89 16:36:35 EDT
1653: Date: Thu, 5 Oct 89 16:36:35 EDT
1654: From: [email protected]
1655: Message-Id: <[email protected]>
1656: To: c++-bugs
1657: Subject: CAST is not a permitted struct/union operation
1658:
1659: /* The following code goes through CC ok, but gets errors from cc:
1660:
1661: line 31: CAST is not a permitted struct/union operation
1662: line 31: operands of = have incompatible types
1663: */
1664:
1665: template<class vtype>
1666: class vpointer { public:
1667: int foo;
1668: vpointer(){};
1669: vpointer(vpointer<vtype>& v) {foo = v.foo;};
1670: int operator==(vpointer<vtype> const&v) const { return (foo == v.foo); };
1671: };
1672:
1673: template<class t>
1674: class attribute { public:
1675: t rep;
1676: operator t() {return rep;};
1677: attribute(){}; // if these constructors are removed
1678: attribute(attribute& v) {rep = v.rep;}; // then the 2nd error dissappears
1679: };
1680:
1681: class c { public:
1682: attribute<vpointer<int> > foo;
1683: };
1684:
1685: main()
1686: {
1687: c a, b;
1688:
1689: if (a.foo == b.foo);
1690: }
1691: &&&&
1692: &&&&
1693: Return-Path: <[email protected]>
1694: Received: from pigpen.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1695: id AA18060; Thu, 5 Oct 89 16:40:22 EDT
1696: Received: by pigpen.odi.com (4.0/SMI-4.0/ODI-C2)
1697: id AA16396; Thu, 5 Oct 89 16:40:19 EDT
1698: Date: Thu, 5 Oct 89 16:40:19 EDT
1699: From: [email protected]
1700: Message-Id: <[email protected]>
1701: To: c++-bugs
1702: Subject: CAST still not permitted
1703:
1704: /* whoops -- I just realized that the templates were a red herring;
1705: the same error occurs without templates: */
1706:
1707: /* The following code goes through CC ok, but gets errors from cc:
1708:
1709: line 29: CAST is not a permitted struct/union operation
1710: line 29: operands of = have incompatible types
1711: */
1712:
1713: class vpointer { public:
1714: int foo;
1715: vpointer(){};
1716: vpointer(vpointer& v) {foo = v.foo;};
1717: int operator==(vpointer const&v) const { return (foo == v.foo); };
1718: };
1719:
1720: class attribute { public:
1721: vpointer rep;
1722: operator vpointer() {return rep;};
1723: attribute(){}; // if these constructors are removed
1724: attribute(attribute& v) {rep = v.rep;}; // then the 2nd error dissappears
1725: };
1726:
1727: class c { public:
1728: attribute foo;
1729: };
1730:
1731: main()
1732: {
1733: c a, b;
1734:
1735: if (a.foo == b.foo);
1736: }
1737:
1738: &&&&
1739: &&&&
1740: Return-Path: <[email protected]>
1741: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1742: id AA19948; Fri, 6 Oct 89 14:34:59 EDT
1743: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1744: id AA00311; Fri, 6 Oct 89 14:34:57 EDT
1745: Date: Fri, 6 Oct 89 14:34:57 EDT
1746: From: [email protected]
1747: Message-Id: <[email protected]>
1748: To: c++-bugs
1749: Subject: compile time checking of pure virtual functions is suspect
1750:
1751:
1752: The following compiles without error, even though it should according
1753: to section 10.3.
1754:
1755:
1756: class b1 {
1757:
1758: virtual foo() ;
1759: } ;
1760:
1761:
1762: class b2 {
1763: virtual foo() = 0 ;
1764: } ;
1765:
1766:
1767: class d : public b1, public b2 {
1768: } ;
1769:
1770:
1771: Note that modifying the derivation order so that b2 precedes b1 in the
1772: definition of the class "d", results in an appropriate error message,
1773: reproduced at the end of this message. According to section 10.1
1774: order of derivation is not supposed to be significant except for
1775: default initialization, cleanup, and storage layout.
1776:
1777:
1778:
1779:
1780:
1781: CC -I/usr1/sam/2.0/test/ -I /odi/include +e0 -F /tmp/x.C -c > /dev/null
1782: "/usr1/sam/2.0/test/x.C", line 12: error: cannot inherit pure virtual function b2::foo()
1783:
1784: Compilation finished at Fri Oct 6 14:27:23
1785: &&&&
1786: &&&&
1787: Return-Path: <[email protected]>
1788: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1789: id AA26627; Tue, 10 Oct 89 11:56:10 EDT
1790: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1791: id AA02816; Tue, 10 Oct 89 11:56:09 EDT
1792: Date: Tue, 10 Oct 89 11:56:09 EDT
1793: From: [email protected]
1794: Message-Id: <[email protected]>
1795: To: c++-bugs
1796: Cc: bob
1797: Subject: pure virtual destructors
1798:
1799:
1800:
1801: Pure virtual destructors appear to be broken in two ways:
1802:
1803: a) The derived class buit from the abstract class is not checked to
1804: ensure that it defines a virtual destructor.
1805:
1806: b) Section 10.3 of the PRM states that a pure virtual function must be
1807: defined if it is called explicitly. In the example below, the
1808: destructor is called "explicitly" by the compiler as part of the code
1809: generated for the destructors of the derived type. I think it
1810: is just the documentation that is remiss here.
1811:
1812:
1813: The moral of the story seems to be that if you have defined a pure
1814: virtual destructor you must define a body for it. The hack (= 0)
1815: syntax prevents you from defining the body at the same time that you
1816: define it "pure", so you must do it outside the class declaration.
1817:
1818:
1819:
1820: class base {
1821: protected:
1822: int a;
1823:
1824: public:
1825: base( int anA);
1826: virtual ~base() = 0;
1827: };
1828:
1829: class derived : public base {
1830: protected:
1831: int b;
1832:
1833: public:
1834: derived( int anA, int aB);
1835: virtual ~derived(); // commenting out this line doesn't provoke an error
1836: // message
1837: };
1838:
1839: base::base( int anA) {
1840: }
1841:
1842: derived::derived( int anA, int aB) : base( anA) {
1843: }
1844:
1845: derived::~derived() {
1846: }
1847:
1848: base::~base(){}
1849:
1850: main(){}
1851: &&&&
1852: &&&&
1853: Return-Path: <[email protected]>
1854: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1855: id AA27198; Tue, 10 Oct 89 16:29:51 EDT
1856: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1857: id AA02918; Tue, 10 Oct 89 16:29:47 EDT
1858: Date: Tue, 10 Oct 89 16:29:47 EDT
1859: From: [email protected]
1860: Message-Id: <[email protected]>
1861: To: c++-bugs
1862: Subject: default arguments
1863:
1864:
1865: It would seem that the default arguments for a virtual function
1866: should have the same initialization expression in the base and derived
1867: types. Otherwise, since the evaluation of the default argument is
1868: performed at the point of call, the expression used for the default
1869: initialization may not correspond to the virtual function that is
1870: actually run for the object !
1871:
1872:
1873: This may be a language bug rather than a cfront bug, since I can't
1874: find any such strictures on default arguments in the PRM.
1875:
1876:
1877: class b {
1878: public:
1879: virtual foo(int i = 5) ;
1880: } ;
1881:
1882:
1883: class d : public b {
1884: public:
1885: virtual foo(int i = 6) ; // different initialization
1886: } ;
1887:
1888: foo(d *dp) {
1889: b *bp = d ;
1890:
1891: bp->foo() ; // uses i = 5, even though the "most derived type" of
1892: // bp * is a d, and d::foo is the function that would
1893: // actually be invoked.
1894: dp->foo() ; // uses i = 6
1895: }
1896: &&&&
1897: &&&&
1898: Return-Path: <[email protected]>
1899: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1900: id AA27291; Tue, 10 Oct 89 16:56:56 EDT
1901: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1902: id AA03101; Tue, 10 Oct 89 16:56:54 EDT
1903: Date: Tue, 10 Oct 89 16:56:54 EDT
1904: From: [email protected]
1905: Message-Id: <[email protected]>
1906: To: c++-bugs
1907: Subject: incorrect error message
1908:
1909:
1910:
1911: A missing destructor member declaration, derived::~derived in this
1912: case results in a very misleading error message.
1913:
1914:
1915: class base {
1916: public:
1917: base();
1918: virtual ~base() ;
1919: };
1920:
1921:
1922: class derived : public base {
1923: public:
1924: derived();
1925: };
1926:
1927: derived::~derived() {
1928: }
1929:
1930: CC -I/usr1/sam/2.0/test/ -I /odi/include +e0 -F /tmp/vd.C -c > /dev/null
1931: "/usr1/sam/2.0/test/vd.C", line 13: error: two definitions of derived::~derived()
1932:
1933: Compilation finished at Tue Oct 10 16:52:59
1934: &&&&
1935: &&&&
1936: Return-Path: <[email protected]>
1937: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1938: id AA27460; Tue, 10 Oct 89 18:54:22 EDT
1939: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
1940: id AA03209; Tue, 10 Oct 89 18:54:21 EDT
1941: Date: Tue, 10 Oct 89 18:54:21 EDT
1942: From: [email protected]
1943: Message-Id: <[email protected]>
1944: To: c++-bugs
1945: Subject: more name visibility lossage (how bankrupt can a symbol table be)
1946:
1947:
1948:
1949: Members defined in a base class but accessed from within a derived class
1950: provoke syntax errors when the member name is shadowed by a global
1951: type name.
1952:
1953:
1954: Note that it is ok to access a a member in the immediate class even if
1955: it is shadowed as above.
1956:
1957:
1958:
1959: typedef unsigned char t ;
1960: typedef unsigned char t1 ;
1961:
1962: class b {
1963: public:
1964: int t ;
1965: } ;
1966:
1967: class d : public b {
1968: int t1 ;
1969: foo() {
1970: t1 = 0 ; // t1 is ok since it is local
1971: t = 0 ; // incorrect error by cfront here
1972: }
1973: bar() ;
1974: } ;
1975:
1976:
1977: d::bar() { t = 0 ; } // incorrect error by cfront here
1978: &&&&
1979: &&&&
1980: Return-Path: <[email protected]>
1981: Received: from pigpen.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
1982: id AA28825; Wed, 11 Oct 89 09:12:07 EDT
1983: Received: by pigpen.odi.com (4.0/SMI-4.0/ODI-C2)
1984: id AA19362; Wed, 11 Oct 89 09:12:05 EDT
1985: Date: Wed, 11 Oct 89 09:12:05 EDT
1986: From: [email protected]
1987: Message-Id: <[email protected]>
1988: To: [email protected], [email protected]
1989: Subject: Re: default arguments
1990:
1991: Date: Tue, 10 Oct 89 16:29:47 EDT
1992: From: [email protected]
1993:
1994: It would seem that the default arguments for a virtual function
1995: should have the same initialization expression in the base and derived
1996: types. Otherwise, since the evaluation of the default argument is
1997: performed at the point of call, the expression used for the default
1998: initialization may not correspond to the virtual function that is
1999: actually run for the object !
2000:
2001: This may be a language bug rather than a cfront bug, since I can't
2002: find any such strictures on default arguments in the PRM.
2003:
2004: class b {
2005: public:
2006: virtual foo(int i = 5) ;
2007: } ;
2008:
2009: class d : public b {
2010: public:
2011: virtual foo(int i = 6) ; // different initialization
2012: } ;
2013:
2014: foo(d *dp) {
2015: b *bp = d ;
2016:
2017: bp->foo() ; // uses i = 5, even though the "most derived type" of
2018: // bp * is a d, and d::foo is the function that would
2019: // actually be invoked.
2020: dp->foo() ; // uses i = 6
2021: }
2022:
2023: I am not even completely convinced that this is a language bug (on the
2024: other hand I am hesitant to call it exactly a feature either -- it's
2025: firmly in that grey area in between). Since default arg selection
2026: happens at compile time, of course it cannot use the actual type of
2027: the object, it can only use the declared type. But what's so wrong
2028: with that? Sure, it might be confusing to some users, but that seems
2029: like a scant motivation for labelling it a "bug", since it might
2030: actually be useful in some cases:
2031:
2032: class person { public:
2033: virtual void hire(char* job_title, int starting_salary = MINIMUM_WAGE);
2034: };
2035:
2036: class college_graduate : public person { public:
2037: virtual void hire(char* job_title, int starting_salary = 30000);
2038: };
2039:
2040: main() {
2041: college_graduate *g = new college_graduate;
2042: person *p = g;
2043:
2044: p->hire("box packer"); /* minimum wage, who cares if she went to college */
2045: g->hire("CEO"); /* for a job like this, she better be a grad,
2046: * and she should get paid accoringly */
2047: }
2048:
2049: I'm not sure if this is a convincing argument that this isn't a bug;
2050: but on the other hand, I don't see a strong argument that it is a bug
2051: either. Users just have to get their heads around a slightly
2052: complicated rule: for virtual functions, the function body chosen
2053: depends on the actual type of the object, but the default args depend
2054: on its declared type.
2055:
2056: $.02
2057: -Gordon
2058: &&&&
2059: &&&&
2060: Return-Path: <[email protected]>
2061: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2062: id AA02033; Thu, 12 Oct 89 14:13:37 EDT
2063: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
2064: id AA23840; Thu, 12 Oct 89 14:13:35 EDT
2065: Date: Thu, 12 Oct 89 14:13:35 EDT
2066: From: [email protected]
2067: Message-Id: <[email protected]>
2068: To: c++bugs
2069: Subject: multiple uses of constr
2070:
2071:
2072: consider:
2073:
2074: class foo {} ;
2075:
2076: typedef foo * FOO;
2077: typedef FOO const FOOc;
2078: typedef FOOc const FOOcc;
2079:
2080: if c++ was like ansi C, the last typedef would be invalid.
2081: Instead, it is permitted, but a FOOcc cannot be passed as a FOOc.
2082: The code in type::check adds 1 to cnst1 or cnst2 for each const that it
2083: sees, and then makes various arithmetic comparisons.
2084:
2085: Whatever this means, it can't be true that two const's is more const
2086: than one const. Either type::check should use |=, or the grammar should
2087: catch and yell about the last typedef above.
2088: &&&&
2089: &&&&
2090: Return-Path: <[email protected]>
2091: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2092: id AA17710; Thu, 19 Oct 89 15:06:19 EDT
2093: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
2094: id AA01604; Thu, 19 Oct 89 15:06:17 EDT
2095: Date: Thu, 19 Oct 89 15:06:17 EDT
2096: From: [email protected]
2097: Message-Id: <[email protected]>
2098: To: c++bugs
2099: Subject: warnings? ! ^!%#%
2100:
2101: Consider this program:
2102:
2103: class C {
2104: int x;
2105: int y;
2106: };
2107:
2108: class D : public C {
2109: public:
2110: D (D &);
2111: D();
2112: int r;
2113: int s;
2114: };
2115:
2116: void x (C &);
2117:
2118: D makec(D&);
2119:
2120: void y ()
2121: {
2122: D q;
2123: int z;
2124:
2125: /* Warning */
2126: x(makec(q));
2127:
2128: /* No Warning */
2129: x((z = 0, makec(q)));
2130: }
2131:
2132: In both cases, the code generates has no temporary.
2133:
2134: (to be precise, the code generated has a temporary passed in as a
2135: result argument, but no copies are made. that temporary is passed
2136: directly to the function X.)
2137:
2138: In call_fct, a G_CM and a temp are built if f_result is non-0,
2139: and that is non-0 because there is a D(D&) constructor. (see
2140: make_res). In the second case, the presence of the comma hides
2141: the so-called temporary from the sight of the code in call_fct
2142: that produces the warning.
2143:
2144: Since the generated code is AOK, its hard to be too upset about this.
2145: but it sure is mystifying.
2146: &&&&
2147: &&&&
2148: Return-Path: <[email protected]>
2149: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2150: id AA26697; Mon, 23 Oct 89 19:38:29 EDT
2151: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
2152: id AA11165; Mon, 23 Oct 89 19:38:26 EDT
2153: Date: Mon, 23 Oct 89 19:38:26 EDT
2154: From: [email protected]
2155: Message-Id: <[email protected]>
2156: To: c++-bugs
2157: Subject: coercions within the operands of a conditional operator are broken
2158:
2159:
2160:
2161: The first operand of a condition operator is not coerced to the result
2162: type, the second operator matches the result type, as in the example below.
2163:
2164: class b0 {
2165: int i ;
2166: } ;
2167:
2168:
2169: class b {
2170: int i ;
2171: virtual f() ;
2172: } ;
2173:
2174: class d : public b0, public b {
2175: public:
2176: int i ;
2177: d (int i) ;
2178: virtual f() ;
2179: } ;
2180:
2181:
2182: int f() ;
2183:
2184: b *lose(d *dp, b* bp)
2185: {
2186: bp = (f() ? dp : bp) ; // incorrect code, no coercion of dp
2187:
2188: return (f() ? dp : bp) ; // same bug
2189: }
2190: &&&&
2191: &&&&
2192: Return-Path: <[email protected]>
2193: Received: from mojo.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2194: id AA01763; Wed, 25 Oct 89 13:25:14 EDT
2195: Received: by mojo.odi.com (4.0/SMI-4.0/ODI-C2)
2196: id AA04012; Wed, 25 Oct 89 13:25:11 EDT
2197: Date: Wed, 25 Oct 89 13:25:11 EDT
2198: From: [email protected]
2199: Message-Id: <[email protected]>
2200: To: c++-bugs
2201: Subject: You can't new a pointer to member function
2202:
2203:
2204: Compiling the following program
2205:
2206: /* This may look like C code, but it is really -*- C++ -*- */
2207:
2208: struct MF_01_tk_01 {
2209: char char_00, char_01, char_02, char_03;
2210: char fun_00();
2211: };
2212: struct MF_01_tk_02 : public MF_01_tk_01 {
2213: char fun_01();
2214: };
2215:
2216: void *MF_new_01()
2217: {
2218: typedef char (MF_01_tk_01::*MFp)();
2219: return (void *)(new MFp(MF_01_tk_02::fun_00));
2220: }
2221:
2222: produces the not immediately comprehensible error messages
2223:
2224: "MF_new_01.C", line 15: syntax error at or near symbol {
2225: "MF_new_01.C", line 14: syntax error at or near symbol }
2226: "MF_new_01.C", line 17: syntax error
2227:
2228: from cc (not CC).
2229: &&&&
2230: &&&&
2231: Return-Path: <[email protected]>
2232: Received: from moon.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2233: id AA04140; Thu, 26 Oct 89 11:08:45 EDT
2234: Received: by moon.odi.com (4.0/SMI-4.0/ODI-C2)
2235: id AA16204; Thu, 26 Oct 89 11:08:42 EDT
2236: Date: Thu, 26 Oct 89 11:08:42 EDT
2237: From: [email protected]
2238: Message-Id: <[email protected]>
2239: To: c++-bugs
2240: Subject: bit field packing
2241:
2242:
2243:
2244: cfront incorrectly estimates the size of classes containing
2245: bit fields. Consequently, when casting a derived class pointer
2246: to a pointer to one of its base classes which contains a bit field,
2247: the wrong offset may be added to the derived class pointer.
2248:
2249: The field basecl::obj_offset is getting the wrong value as
2250: cfront assumes each bit fields to be aligned on a byte
2251: boundary.
2252:
2253: The places to look.
2254:
2255: Allocating base class objects: probably the culprit, but given
2256: cfront's method of code reuse (cut and paste) the other places
2257: probably need to be checked.
2258:
2259: dcl4.c:1349: l->obj_offset = boff;
2260:
2261: Allocating virtual base classes
2262:
2263: dcl4.c:1764: if (b->obj_offset = has_allocated_base(bcl)) continue;
2264:
2265: dcl4.c:1771: b->obj_offset = byte_offset; // offset in this
2266:
2267:
2268: Generating destructors for both non-virtual and virtual base
2269: classes.
2270:
2271: simpl.c:555: x->obj_offset = l->obj_offset;
2272:
2273: simpl.c:562: b->obj_offset = l->obj_offset;
2274:
2275:
2276: Test Code
2277: ---------
2278:
2279:
2280: #include <iostream.h>
2281:
2282: typedef unsigned int uint ;
2283:
2284:
2285: class A {
2286: public:
2287: char c;
2288: A () { c = 0; }
2289: };
2290:
2291: class bit_fields_1 {
2292:
2293: public:
2294: uint file_index : 10;
2295: uint line_no : 22;
2296:
2297: bit_fields_1 () { file_index = 0; line_no = 0; };
2298:
2299: };
2300:
2301:
2302: class bit_fields_2 {
2303:
2304: public:
2305: uint file_index : 10,
2306: line_no : 22;
2307:
2308: bit_fields_2 () { file_index = 0; line_no = 0; };
2309:
2310: };
2311:
2312:
2313: class B {
2314: public:
2315: int v;
2316:
2317: B () { v = 0xaaaa; };
2318:
2319: };
2320:
2321: class D1 : public A, public bit_fields_1, public B {
2322: };
2323:
2324: class D2 : public A, public bit_fields_2, public B {
2325: };
2326:
2327:
2328: int works_as_B (B *b)
2329: {
2330:
2331: if (b->v == 5)
2332: return 1;
2333: else
2334: return 0;
2335:
2336: }
2337:
2338:
2339: int main ()
2340: {
2341:
2342: int passed = 1;
2343:
2344: D1 d1;
2345: if ( ! works_as_B(&d1)) {
2346: cout << "FAILED: d1 doesn't work as B" << endl;
2347: cout << "\tsizeof(D1) = " << sizeof(D1) << endl;
2348: passed = 0;
2349: }
2350:
2351: D2 d2;
2352: if ( ! works_as_B(&d2)) {
2353: cout << "FAILED: d2 doesn't work as B" << endl;
2354: cout << "\tsizeof(D2) = " << sizeof(D2) << endl;
2355: passed = 0;
2356: }
2357:
2358: if (passed)
2359: cout << "PASSED" << endl;
2360:
2361: }
2362:
2363:
2364:
2365: -Rick
2366: &&&&
2367: &&&&
2368: Return-Path: <[email protected]>
2369: Received: from pigpen.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2370: id AA03326; Tue, 31 Oct 89 15:28:12 EST
2371: Received: by pigpen.odi.com (4.0/SMI-4.0/ODI-C2)
2372: id AA01538; Tue, 31 Oct 89 15:28:08 EST
2373: Date: Tue, 31 Oct 89 15:28:08 EST
2374: From: [email protected]
2375: Message-Id: <[email protected]>
2376: To: c++-bugs
2377: Subject: bad template ref member inits not caught
2378:
2379: The following file appropriately fails to compile:
2380:
2381: struct A {
2382: int& i;
2383: A() : i() {};
2384: };
2385:
2386: generating the errors:
2387:
2388: "t.C", line 1: error: empty initializer for reference A::i
2389: "t.C", line 1: error: reference member A::i needs initializer
2390:
2391: But if you hide the ref member inside a template parameter,
2392: cfront dies with a core dump:
2393:
2394: template<class T>
2395: struct A {
2396: T i;
2397: A() : i() {};
2398: };
2399:
2400: static A<int&> a;
2401: &&&&
2402: &&&&
2403: Return-Path: <[email protected]>
2404: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2405: id AA02618; Wed, 1 Nov 89 13:44:45 EST
2406: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
2407: id AA04946; Wed, 1 Nov 89 13:44:37 EST
2408: Date: Wed, 1 Nov 89 13:44:37 EST
2409: From: [email protected]
2410: Message-Id: <[email protected]>
2411: To: [email protected]
2412: Cc: c++-bugs
2413: In-Reply-To: [email protected]'s message of Tue, 31 Oct 89 15:28:08 EST <[email protected]>
2414: Subject: bad template ref member inits not caught(actually bad typedefed ref member inits not caught)
2415:
2416: Date: Tue, 31 Oct 89 15:28:08 EST
2417: From: [email protected]
2418:
2419: The following file appropriately fails to compile:
2420:
2421: struct A {
2422: int& i;
2423: A() : i() {};
2424: };
2425:
2426: generating the errors:
2427:
2428: "t.C", line 1: error: empty initializer for reference A::i
2429: "t.C", line 1: error: reference member A::i needs initializer
2430:
2431: But if you hide the ref member inside a template parameter,
2432: cfront dies with a core dump:
2433:
2434: template<class T>
2435: struct A {
2436: T i;
2437: A() : i() {};
2438: };
2439:
2440: static A<int&> a;
2441:
2442: The problem is template independent. The case below will blow up in
2443: the same way, a fix is on the way.
2444:
2445: typedef int & x ;
2446: struct A {
2447: x i;
2448: A() : i() {};
2449: };
2450:
2451: &&&&
2452: &&&&
2453: Return-Path: <[email protected]>
2454: Received: from cass.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2455: id AA13420; Mon, 6 Nov 89 10:35:39 EST
2456: Received: by cass.odi.com (4.0/SMI-4.0/ODI-C2)
2457: id AA04499; Mon, 6 Nov 89 10:35:37 EST
2458: Date: Mon, 6 Nov 89 10:35:37 EST
2459: From: [email protected]
2460: Message-Id: <[email protected]>
2461: To: c++bugs
2462: Subject: how to confuse const checking
2463:
2464: The following program:
2465:
2466: /* -*- Mode:C++ -*- */
2467:
2468: int gruz (char *, char *);
2469: int gruz (char const *, char const *);
2470:
2471: void plugh (char const * x, char * y)
2472: {
2473: gruz(x,y);
2474: }
2475:
2476: gets the following error:
2477:
2478: CC foo.C:
2479: "foo.C", line 8: error: two exact matches for gruz(): int (const char *, const c
2480: har *) and int (char *, char *)
2481: 1 error
2482: &&&&
2483: &&&&
2484: Return-Path: <[email protected]>
2485: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2486: id AA13457; Mon, 6 Nov 89 10:46:49 EST
2487: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
2488: id AA09132; Mon, 6 Nov 89 10:46:47 EST
2489: Date: Mon, 6 Nov 89 10:46:47 EST
2490: From: [email protected]
2491: Message-Id: <[email protected]>
2492: To: [email protected]
2493: Cc: c++bugs
2494: In-Reply-To: [email protected]'s message of Mon, 6 Nov 89 10:35:37 EST <[email protected]>
2495: Subject: how to confuse const checking
2496:
2497: Date: Mon, 6 Nov 89 10:35:37 EST
2498: From: [email protected]
2499:
2500: The following program:
2501:
2502: /* -*- Mode:C++ -*- */
2503:
2504: int gruz (char *, char *);
2505: int gruz (char const *, char const *);
2506:
2507: void plugh (char const * x, char * y)
2508: {
2509: gruz(x,y);
2510: }
2511:
2512: gets the following error:
2513:
2514: CC foo.C:
2515: "foo.C", line 8: error: two exact matches for gruz(): int (const char *, const c
2516: har *) and int (char *, char *)
2517: 1 error
2518:
2519:
2520: Unfortunately, according to Section 13 of the PRM this error message
2521: is legitimate.
2522: &&&&
2523: &&&&
2524: Return-Path: <[email protected]>
2525: Received: from joplin.odi.com by odi.com (4.0/SMI-4.0/ODI-4)
2526: id AA13519; Mon, 6 Nov 89 11:01:50 EST
2527: Received: by joplin.odi.com (4.0/SMI-4.0/ODI-C2)
2528: id AA09163; Mon, 6 Nov 89 11:01:47 EST
2529: Date: Mon, 6 Nov 89 11:01:47 EST
2530: From: [email protected]
2531: Message-Id: <[email protected]>
2532: To: [email protected]
2533: Cc: c++bugs
2534: In-Reply-To: [email protected]'s message of Mon, 6 Nov 89 10:35:37 EST <[email protected]>
2535: Subject: how to confuse const checking
2536:
2537:
2538: Upon further reflection there is a bug here. It shouldn't have been
2539: possible to define the second gruz, ie. the following abbreviated
2540: test should fail, but doesn't.
2541: ---------
2542:
2543: int gruz (char *, char *);
2544: int gruz (const char *, const char *);
2545:
2546: ----------
2547:
2548:
2549: Date: Mon, 6 Nov 89 10:35:37 EST
2550: From: [email protected]
2551:
2552: The following program:
2553:
2554: /* -*- Mode:C++ -*- */
2555:
2556: int gruz (char *, char *);
2557: int gruz (char const *, char const *);
2558:
2559: void plugh (char const * x, char * y)
2560: {
2561: gruz(x,y);
2562: }
2563:
2564: gets the following error:
2565:
2566: CC foo.C:
2567: "foo.C", line 8: error: two exact matches for gruz(): int (const char *, const c
2568: har *) and int (char *, char *)
2569: 1 error
2570:
2571:
2572: Unfortunately, according to Section 13 of the PRM this error message
2573: is legitimate.
2574: &&&&
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.