![[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.