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.