keppel@pavepaws.berkeley.edu (David Keppel) (05/28/86)
< munchies! > [ discription of problem "'if (a=b)' when I wanted 'if (a==b)'" ] How about an option to lint(1) (this doesn't help the people who don't have lint) that looks for conditional clauses with assignment but no test. Thus if ( (a = expr) == value ) { ... would pass cleanly thru lint, while if ( a = expr ) { ... would generate a message indicating a potential problem. There could be a "lint comment" /* BOOLTESTED */ or some such: if ( a = expr ) { /* BOOLTESTED */ that would also serve as documentation to say to another reader of the code "Yes, I really meant '=' and not '=='". ---- David Keppel ..!ucbvax!pavepaws!keppel "Gospel in, Gospel out: Learning by Osmosis"
bright@dataioDataio.UUCP (Walter Bright) (05/29/86)
In article <446@cad.BERKELEY.EDU> keppel@pavepaws.UUCP (David Keppel) writes: > How about an option to lint(1) (this doesn't help the people who > don't have lint) that looks for conditional clauses with assignment > but no test. Thus > if ( (a = expr) == value ) { ... > would pass cleanly thru lint, while > if ( a = expr ) { ... > would generate a message indicating a potential problem. Datalight C generates a warning for this: if ( a = expr) { ^ Warning: possible unintended assignment. In fact, it will also generate the same warning for stuff like: !(a = expr) (e1 == e2 && e3 = e4) etc. > There could be a "lint comment" /* BOOLTESTED */ or some such: > if ( a = expr ) { /* BOOLTESTED */ > that would also serve as documentation to say to another reader of > the code "Yes, I really meant '=' and not '=='". The BOOLTESTED is unnecessary. Simply write: if ((a = expr) != 0) { which will not trigger the warning.