phil@sivax.UUCP (Phil Hunt) (09/25/86)
Hello,
I pulled down the VT100 V2.1 sources and compiled them with Lattice 'C'
v3.03 after setting VT100.h to LATTICE.
It worked ok, but had some questions about some warnings I recieved.
In the module Script.c, I recieved 2 warning:
Line 427 and 490, Warning 85: Function return value mismatch
any ideas?
I am just learning 'C', so it is all new to me.
Phil Hunt
..calma!sivax!phildaveh@cbmvax.cbm.UUCP (Dave Haynie) (09/26/86)
> > Hello, > > I pulled down the VT100 V2.1 sources and compiled them with Lattice 'C' > v3.03 after setting VT100.h to LATTICE. > It worked ok, but had some questions about some warnings I recieved. > In the module Script.c, I recieved 2 warning: > > Line 427 and 490, Warning 85: Function return value mismatch > > I am just learning 'C', so it is all new to me. > > Phil Hunt > ..calma!sivax!phil Lattice incorporates some of the ANSI extensions, and you've just hit upon one of them, better type checking. Normal C compilers let you do many kinds of implicit convertions without telling you about it. Lattice still does the conversions, only it warns you about them. The most common instance of this I've seen is in functions that look something like: funct() { .... return; } Most C compilers won't say anything about this, but technically its wrong. When you specify "funct()" as above, it defaults to a function returning an integer. The return statement, however, isn't returning anything. Lattice would be happier with either of the following: funct() void funct() { { ... ... return 0; return; } } The first example explicitly returns a number, the second example explicitly defines a function that is supposed to have no result. Note that Lattice WILL produce working code in all three cases, only that in the first case it will generate a warning. -- ============================================================================ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh These opinions are my own, though if you try them out, and decide that you really like them, a small donation would be appreciated.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/26/86)
>Phil Hunt writes: > Line 427 and 490, Warning 85: Function return value mismatch > > any ideas? > > I am just learning 'C', so it is all new to me. The author did something like: ptr = function() Where the function returned an integer and not a pointer. It's only a warning on Lattice becomes integers and pointers are the same size anyway. You can ignore such error's for the most part (it's the authors fault), but don't You get into the habit. The correct method (via an example): extern char *function(); char *ptr; . . . ptr = function(); As you can see, it's a little more hassle, but it's correct. -Matt
mwm@eris.berkeley.edu (Mike Meyer) (09/27/86)
In article <8609261713.AA28743@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >>Phil Hunt writes: >> Line 427 and 490, Warning 85: Function return value mismatch >> any ideas? > > The author did something like: > > ptr = function() > > Where the function returned an integer and not a pointer. It's only >a warning on Lattice becomes integers and pointers are the same size anyway. I'm surprised. Matt's statement of fact are usually correct, but not in this case. He's right so often I double-checked the manual to make sure my memory wasn't wrong. Lo and behold, we find: 85 [...] The expression specifying the value to be returned by a function was not of the same type as the function itself. In other words, the expression on a return statement had the wrong type. The compiler usually casts them to the correct type, if possible (this is correct ANSI/K&R behavior) and issues the warning. However, the most common code that generates this warning looks like: func() { /* Declare function returning int */ ... return ; /* No return value! */ } When it should actually be: void func() { /* No value returned */ ... return ; /* Sure enough, ... */ } This is just a minor problem, and will usually do what you want. Like Matt's example, though, it's a bad habit to get into. On the other hand, if the function really returns something, then this is a bug. <mike
hamilton@uiucuxc.CSO.UIUC.EDU (09/28/86)
>>Phil Hunt writes: >> Line 427 and 490, Warning 85: Function return value mismatch >> >> any ideas? >> >> I am just learning 'C', so it is all new to me. > > The author did something like: > > ptr = function() > > Where the function returned an integer and not a pointer. It's only >a warning on Lattice becomes integers and pointers are the same size anyway. >You can ignore such error's for the most part (it's the authors fault), but >don't You get into the habit. The correct method (via an example): i think my manx compiler would have emitted warnings about such cases, but it didn't (i got pristine-clean compiles, if i remember right). also, "return value mismatch" sounds a bit like (eg) a routine declared "char" return()ing a pointer. i just glanced at script.c, and it looks to me like it's all done right. is it possible that, for example, the "*" in char *foo(...) {...} got misplaced somewhere in your copy? wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton ARPA: hamilton%uiucuxc@a.cs.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uiucuxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
daveh@cbmvax.cbm.UUCP (Dave Haynie) (09/29/86)
> Nf-ID: #R:sivax.UUCP:344:uiucuxc:148600149:000:1225 > Nf-From: uiucuxc.CSO.UIUC.EDU!hamilton Sep 27 17:13:00 1986 > i think my manx compiler would have emitted warnings about such cases, > but it didn't (i got pristine-clean compiles, if i remember right). also, > "return value mismatch" sounds a bit like (eg) a routine declared "char" > return()ing a pointer. No, Aztec won't emit such warnings. Aztec is much closer to the original K & R C language, which Lattice has a number of enhancements based on the emerging ANSI standard. Note that they're only warnings, and except for the case of trying to use 16 bit integers as pointers in Aztec (you'll see this kind of thing done in lots of UN*X code; bets to port UN*X stuff to a 32 bit "int" compiler, like cc +l under Aztec), the Aztec and Lattice compilers would produce equivalent code. But you won't get the warning from Aztec. > wayne hamilton > U of Il and US Army Corps of Engineers CERL -- ============================================================================ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh These opinions are my own, though if you try them out, and decide that you really like them, a small donation would be appreciated.