rcj@burl.UUCP (Curtis Jackson) (06/05/86)
Hi. We're talking SVR2 Unix on a Vax 11/780 here. A novice user
was playing around with C and wrote a program that started like
this:
int f1, f2; /* other variable declarations, too */
main(argc,argv)
int argc, f1, f2;
char **argv;
{
On lines 27 and 30 of his program, he referenced the variable "f2".
Our illustrious (actually usually pretty damn good) C compiler said:
27: warning: bad arg temp
30: warning: bad arg temp
And that is it; there is nothing resembling "temp" in the program.
How informative can ya get for your novices? ;-)
--
The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd allegra ]!burl!rcj
...![ ihnp4 cbosgd akgua watmath ]!clyde!rcjguy@sun.UUCP (06/07/86)
> Hi. We're talking SVR2 Unix on a Vax 11/780 here. This is a close-to-universal PCC bug (most PCC bugs not involved in code generation are, alas); read on, even if you aren't running S5R2 on a VAX. > A novice user was playing around with C and wrote a program that started > like this: > > int f1, f2; /* other variable declarations, too */ > main(argc,argv) > int argc, f1, f2; > char **argv; > { > > On lines 27 and 30 of his program, he referenced the variable "f2". > > Our illustrious (actually usually pretty damn good) C compiler said: > > 27: warning: bad arg temp Yup. The trouble is that it didn't catch the error when it should have, and found out that it'd screwed up later. (Why that "bad arg temp" is a warning, I dunno - if it's a compiler bug it should report it as such.) Here's a fix for the S5R2 PCC; the line numbers will be different. It should be obvious how to apply this fix to earlier PCCs, like the S3/4BSD version, as well as to the version hidden away amongst the S3 "lint" source. No guarantees that this won't break anything, but it seems to make sense (after the fix, the rules are "if it was declared as a function argument (i.e., blevel == 1), and if it did not appear in the argument list for that function (i.e., stp != FARG), and if it's not a name of a structure, union, or enum, a member of same, or a typedef, it's an error"), definitely catches the above case, and doesn't seem to choke on other cases. ------- pftn.c ------- *** /tmp/da5007 Fri Jun 6 20:58:37 1986 --- pftn.c Fri Jun 6 17:18:31 1986 *************** *** 81,104 **** if( stp == FTN && p->sclass == SNULL )goto enter; /* name encountered as function, not yet defined */ - if( stp == UNDEF|| stp == FARG ){ - if( blevel==1 && stp!=FARG ) switch( class ){ ! default: ! /* "declared argument %.8s is missing" */ ! /* "declared argument %s is missing" */ ! if(!(class&FIELD)) UERROR( MESSAGE( 28 ), p->sname ); ! case MOS: ! case STNAME: ! case MOU: ! case UNAME: ! case MOE: ! case ENAME: ! case TYPEDEF: ! ; ! } ! goto enter; } if( type != stp ) goto mismatch; /* test (and possibly adjust) dimensions */ --- 81,104 ---- if( stp == FTN && p->sclass == SNULL )goto enter; /* name encountered as function, not yet defined */ ! if( blevel==1 && stp!=FARG ) switch( class ){ ! ! default: ! /* "declared argument %.8s is missing" */ ! /* "declared argument %s is missing" */ ! if(!(class&FIELD)) UERROR( MESSAGE( 28 ), p->sname ); ! case MOS: ! case STNAME: ! case MOU: ! case UNAME: ! case MOE: ! case ENAME: ! case TYPEDEF: ! ; } + + if( stp == UNDEF|| stp == FARG ) goto enter; if( type != stp ) goto mismatch; /* test (and possibly adjust) dimensions */ -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
chris@umcp-cs.UUCP (Chris Torek) (06/07/86)
In article <1297@burl.UUCP> rcj@burl.UUCP (Curtis Jackson) writes: [code such as] >int f1, f2; /* other variable declarations, too */ >main(argc,argv) >int argc, f1, f2; [produces] >27: warning: bad arg temp >30: warning: bad arg temp The `temp' referred to is, of course, entirely in the mind of the compiler. I was, however, surprised that PCC emits a warning for this; it seems to me it should be classified as a compiler error. Whether the message "foo.c", line 27: compiler error: bad arg temp would be any less confusing is uncertain. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
guy@sun.uucp (Guy Harris) (06/10/86)
> Whether the message > > "foo.c", line 27: compiler error: bad arg temp > > would be any less confusing is uncertain. Well, if your users are aware that "compiler error" really means "bring this message, along with the source code, to your local support person", I think it is certain that it is less confusing. Unless a user knows the innards of the program they're using, they should treat messages of that sort ("compiler error: <blahblahblah>", "panic: <blahblahblah>", etc.) as strings not to be interpreted, but to be carted to somebody who *does* know the innards of that program; in that case, there's nothing to be confused about. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
tanner@ki4pv.UUCP (Tanner Andrews) (06/12/86)
) guy@sun.UUCP writes ) ... if your users are aware that "compiler error" really means "bring this ) message, along with the source code, to your local support person", ... I must take some exception to this. Your local support person is too busy to tell 50 people that "compiler error: gork blunge snarf" means "formal not declared on argument list". For shame! If (when the time comes to decide where in the argument list you found the item to be bound) you can't find it in the argument list, you should make a good effort to emit a useful error. Failing that, publish a list of compiler errors as part of the error list so we know that "gork blunge snarf" means "one of your formal declarations was not on arg list". -- <std dsclm, copies upon request> Tanner Andrews
guy@sun.uucp (Guy Harris) (06/14/86)
> ) ... if your users are aware that "compiler error" really means "bring this > ) message, along with the source code, to your local support person", ... > > I must take some exception to this. Your local support person is too busy > to tell 50 people that "compiler error: gork blunge snarf" means "formal not > declared on argument list". I must take some exception to this. You're assuming that "compiler error: <foo bar bletch>" *does* mean "formal not declared on argument list". It doesn't (note that, while the S5 compiler does generate such a message in this case, earlier PCC compilers generate *no* error). What it means is "somebody working on the compiler f***ed up". Your local support person better not be too busy to do the appropriate thing in this instance, which is to take the message, source code, etc., attach it to a bug report, and send it to the vendor. > For shame! If (when the time comes to decide where in the argument list you > found the item to be bound) you can't find it in the argument list, you > should make a good effort to emit a useful error. The problem isn't that it didn't find the item in the argument list, it's that it wasn't in the argument list but it didn't realize it. Since it didn't even think there was an error, it could hardly have made an effort to emit any error message, useful or not. It just put its data structures into an inconsistent state. One version of the compiler (S5, VAX) detected this inconsistency later;, by then, it had no idea what the problem was and couldn't make any effort to say anything more meaningful that "oops!". Other versions of the compiler don't even detect this inconsistency. The fix is to properly check that the item which is allegedly being declared as an argument actually appeared in the argument list; see my recent posting here and in "net.bugs.*" for that fix. > Failing that, publish a list of compiler errors as part of the error > list so we know that "gork blunge snarf" means "one of your formal > declarations was not on arg list". Again, I point out that "gork blunge snarf" doesn't mean "one of your formal declarations wasn't on arg list"! It means "something is fouled up here", and it just so happens that the foulup in this particular case was caused by something being declared, in a scope where declarations are treated as formal argument declarations, and the name hadn't previously appeared in the argument list. If the compiler writer had known that a particular "compiler error" message would be emitted when a particular illegal program were fed to the compiler, they would presumably have fixed the compiler to detect the illegal code and not *get* to the place where the "compiler error" message is emitted! At the back of one of IBM's mainframe PL/I compiler manuals (and probably at the back of all such manuals), there is a long list of error messages. Some of them are "compiler error" messages. They generally don't say "this error really means you put extra crud in a DO statement, but we screwed up the parser so it causes an inconsistent data structure in the compiler which is detected later on." They say "report this to your IBM support person", because it means somebody ran across a *bug* in the compiler which, presumably, the compiler writers didn't know was there. The fact that this particular inconsistency was reported as a "warning" rather than a fatal "compiler error" is probably a botch on the part of one of the compiler maintainers. That isn't, however, germane to this particular discussion. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
bzs@bu-cs.UUCP (Barry Shein) (06/18/86)
) guy@sun.UUCP writes ) ... if your users are aware that "compiler error" really means "bring this ) message, along with the source code, to your local support person", ... )) tanner@ki4pv.UUCP (Tanner Andrews) ))I must take some exception to this. Your local support person is too busy to ))tell 50 people that "compiler error: gork blunge snarf" means "formal not ))declared on argument list". Well, you could always do what the RT11V2 Fortran did on a compiler error: Print out an entire form to be filled out with questions, dashed lines etc on the user's console (real useful on our TEK4010!) with mailing instructions (no joke.) The point is, a compiler bug is a compiler bug, if it knew it was ill because of "formal not declared on argument list" I am sure the compiler writer would have been glad to have included the error message. More likely it just trapped a memory fault or something disasterous like that regardless of what caused it, you're just smarter than the compiler for the moment. Guy is right. -Barry Shein, Boston University