[comp.lang.c] 'Possibly Incorrect Assignment' warnings from Turbo-C

daveh@marob.masa.com (Dave Hammond) (11/25/89)

In porting a program from Unix to Dos, I get an error from Turbo-C
`Possibly incorrect assignment' with code similar to the following:

char *p, *func();

if (p = func())
	do_something();

Am I fooling myself by ass/u/ming that func() will always be invoked
and its return value assigned to p, before p is evaluated ?  Should
I change all such assignments to include an additional set of parens?

if ((p = func()))
	do_something()

--
Dave Hammond
daveh@marob.masa.com

cpcahil@virtech.uucp (Conor P. Cahill) (11/25/89)

In article <256D8362.18B@marob.masa.com>, daveh@marob.masa.com (Dave Hammond) writes:
> In porting a program from Unix to Dos, I get an error from Turbo-C
> `Possibly incorrect assignment' with code similar to the following:
> 
> char *p, *func();
> 
> if (p = func())
> 	do_something();

I think this kind of warning should be generated by all compilers.  What
you did is legal C, but when you go back to it after two or three weeks you
too will have to look at the surrounding code to see if it was supposed to 
be an assignment or comparison operator.

There are several other ways that the same code could be written that would
be just as efficient and not be confusing.

How about:

		p = func();
		if( p )...

Or
		if( (p=func()) != 0 )...


In both of these cases you know that func is assigned to p and the
result is compared to zero.

> Am I fooling myself by ass/u/ming that func() will always be invoked
> and its return value assigned to p, before p is evaluated ?

No func will always be called and the result will be assigned to p.  The
compiler was only warning you that you might have made the same mistake
that every C programmer has made at least once:  using an assignment operator
when a comparitive operator was intended (i.e.  = instead of ==).

>  Should
> I change all such assignments to include an additional set of parens?

This may or may not quiet the compiler, but it does nothing to assure the
reader of the intended operator.


-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+

gwyn@smoke.BRL.MIL (Doug Gwyn) (11/26/89)

In article <256D8362.18B@marob.masa.com> daveh@marob.masa.com (Dave Hammond) writes:
>if (p = func())
>Am I fooling myself by ass/u/ming that func() will always be invoked
>and its return value assigned to p, before p is evaluated ?

That's not what Turbo-C is warning you about.  It thinks you might have
meant to type:
	if (p == func())

Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (11/27/89)

In an article of <24 Nov 89 18:07:29 GMT>, (Dave Hammond) writes:

 >In porting a program from Unix to Dos, I get an error from Turbo-C
 >`Possibly incorrect assignment' with code similar to the following:
 >
 >char *p, *func();
 >
 >if (p = func())
 >        do_something();

The warning (not an error) will go away if you use instead:

        if (0 != (p = func()))
                do_something();

The warning exists because it saw an assignment operator where it expected a  
logical comparison operator. Since typing `=' when you mean `==' is a fairly  
common mistake, it always warns you with the "Possibly incorrect assignement"  
message. 

lwh@harpsichord.cis.ohio-state.edu (Loyde W Hales) (11/28/89)

In article <256D8362.18B@marob.masa.com> daveh@marob.masa.com
(Dave Hammond) writes:
>In porting a program from Unix to Dos, I get an error from Turbo-C
>`Possibly incorrect assignment' with code similar to the following:
>
>char *p, *func();
>
>if (p = func())
>	do_something();
>
>Am I fooling myself by ass/u/ming that func() will always be invoked
>and its return value assigned to p, before p is evaluated ?  Should
>I change all such assignments to include an additional set of parens?
>
>if ((p = func()))
>	do_something()

As far as I can tell, both statements are correct.  (Now, I've been known to
miss some pretty gross things, like my recent adventure in proving that you
can't use *a[i] to mean both *a[i] and (*a)[i] -- less than ten lines from
each other! :-)

Turbo C will _always_ yield the `Possibly incorrect assignement' message if
an assignment is the primary operation for a condition.  This is not because
it isn't valid; it is to flag two of the more common mistakes:

	if (a = b)		instead of	if (a == b)
	if (a = b != error)	instead of	if ((a = b) != error)

You can
	1. Turn off this error message for the code
	2. Use the extra parens.
	3. Ignore it.

I'd suggest the last..only because I never turn off messages and find the
first code example easier to read.

LL


-=-

                                Department of Computer and Information Science
Loyde W. Hales, II                      The Ohio State University
lwh@cis.ohio-state.edu          2036 Neil Avenue Mall, Columbus, Ohio  43201

klink@sce.carleton.ca (Robert Klinkhammer) (11/29/89)

In article <3881.25715D5A@urchin.fidonet.org>, Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) writes:
] In an article of <24 Nov 89 18:07:29 GMT>, (Dave Hammond) writes:
] 
]  >In porting a program from Unix to Dos, I get an error from Turbo-C
]  >`Possibly incorrect assignment' with code similar to the following:
]  >
]  >if (p = func())
]  >        do_something();
] 
] The warning (not an error) will go away if you use instead:
] 
]         if (0 != (p = func()))
]                 do_something();
] 
] The warning exists because it saw an assignment operator where it expected a  
] logical comparison operator. Since typing `=' when you mean `==' is a fairly  
] common mistake, it always warns you with the "Possibly incorrect assignement"  
] message. 

The warning will also go away if you do:

	if ((p = func()) != 0)
		do_something();

which (IMHO) expresses the intent more clearly, and is easier to read than
the above. The original reason for reversing the order of the operands to a
test for equality, was, I think, to protect against the exact type of error
mentioned above. But since Turbo C emits a warning when you type `=' instead
of `==', it would seem that the reversal buys nothing.

   It is also possible to turn off this warning altogether, by passing the
flag "-w-pia" to the Turbo C compiler. This is documented somewhere in the
depths of their extremely verbose manuals.
-- 
**********************************************************************
Robert Klinkhammer          "They recommended euthanasia 
<klink@sce.carleton.ca>     for noncomformists anywhere" -- Asia
**********************************************************************