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 **********************************************************************