carpent@SRC.Honeywell.COM (Todd Carpenter) (10/29/89)
Does free() return a value? It used to, in 5.02. I just installed 5.04, and
attempted to recompile some things, and got errors when checking free() to see
if it returns a fail code.
/* silly code example */
#include <stdlib.h>
main()
{
char *temp;
temp = malloc (6);
strcpy(temp,"Hello");
if (free(temp) != 0)
return (1);
return (0);
}
compile with
>lc -L tmp.
if(free(temp) != 0);
^
tmp.c 7 Error 91: illegal void operand
Any ideas out there? Am I using something wrong that managed to get by 5.02
all right?
-Todd C.mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) (10/30/89)
In article <36769@srcsip.UUCP> carpent@SRC.Honeywell.COM (Todd Carpenter) writes:
<Does free() return a value? It used to, in 5.02. I just installed 5.04, and
<attempted to recompile some things, and got errors when checking free() to see
<if it returns a fail code.
My copy of the dpANS C standard and of K&R 2 both show free as being
void. The 5.02 docs show free as being an int, with an error if the
block wasn't freed.
I suspect that someone at Lattice (or a customer) noticed this, so the
corrected it in the 5.04 release.
<mike
--
The Sword of Damocles is hanging over my head Mike Meyer
And I've got a feeling someone's gonna be cuttin' the thread mwm@berkeley.edu
Oh -- woe is me, My life is a misery ucbvax!mwm
And all I can see is I'm on the start of a pretty big downer mwm@ucbjade.BITNETjac@muslix.llnl.gov (James Crotinger) (10/30/89)
According to Plauger and Brodie, "Standard C", free() is prototyped as "void free(void *ptr)", so this is a change by Lattice to bring 5.04 more in line with the standard. Gee, I wonder if they've fixed main()'s prototype? In versions 4 and 5 they had it prototyped to be type void, when it is supposed to be type int (since you can return the return value). [I still haven't received my 5.04 yet 8-( 8-(. Think it's time to get on the phone to Lattice]. Jim
carpent@SRC.Honeywell.COM (Todd Carpenter) (10/30/89)
>From: jac@muslix.llnl.gov (James Crotinger) Newsgroups: comp.sys.amiga.tech > Organization: Lawrence Livermore National Laboratory/UC Davis Lines: 10 > > According to Plauger and Brodie, "Standard C", free() is prototyped as > "void free(void *ptr)", so this is a change by Lattice to bring 5.04 more Thanks! I got to work and checked my books and found the same thing. I'm surprised they didn't also release errata, or put it in the readme.504 (or if they did, I'm sadly blind). In other news, I can now use the optimizer (on certain modules), and can use the 68881 library. This gives me up to a 20% performance increase over IEEE libraries and nonoptimized compilation. I was thrilled, as I need every bit I can get. I am also _very_ happy the Lattice is providing these upgrades free to registered owners. I wonder if they will institute a maintenance program to recoup some of their mailing costs? As long as we are on the subject of Lattice, why doesn't this macro seem to work? (I'm rather new to macrodom, so this is probably a silly one) I have some terribly long nasty expressions that need to be squared, and SQR(moocow) never returns what I expect: #define SQR(x) (x*x)
new@udel.edu (Darren New) (10/31/89)
In article <1989Oct30.062445.1759@agate.berkeley.edu> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: >My copy of the dpANS C standard and of K&R 2 both show free as being >void. The 5.02 docs show free as being an int, with an error if the >block wasn't freed. Why would a free request fail? Or do you mean that it fails if you attempt to free NULL or non-malloced memory or something? -- Darren
carpent@SRC.Honeywell.COM (Todd Carpenter) (10/31/89)
In article <2933@nigel.udel.EDU> new@udel.edu (Darren New) writes: > > In article <1989Oct30.062445.1759@agate.berkeley.edu> mwm@eris.berkeley.edu (Mike (I'll think of something yet) Meyer) writes: > >My copy of the dpANS C standard and of K&R 2 both show free as being > >void. The 5.02 docs show free as being an int, with an error if the > >block wasn't freed. > > Why would a free request fail? Or do you mean that it fails if > you attempt to free NULL or non-malloced memory or something? > -- Darren That is why I was checking it. Silly me, I read the Lattice Docs, and assumed it returned a value for a reason, and so I checked its return status. I didn't even think of cross referencing to an ANSI book. Heck, I had enough Guru's as it was, freeing up Null pointers... (on which I don't think it returned nicely) -Todd C. Following up on my #define SQR(x) (x*x) silliness, about 10 very kind and polite people pointed out the error. Thank you! I am tearing up my BEE degree and going back to 8th grade math for awhile.
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (10/31/89)
carpent@SRC.Honeywell.COM (Todd Carpenter) writes: > As long as we are on the subject of Lattice, why doesn't this macro seem to > work? (I'm rather new to macrodom, so this is probably a silly one) I > have some terribly long nasty expressions that need to be squared, and > SQR(moocow) never returns what I expect: > > #define SQR(x) (x*x) Well, imagine what happens when you try to SQR(a+b). You get a+b*a+b which doesn't parse as you intended. The solution is to change the macro definition to #define SQR(x) ((x)*(x)) In general, when defining expression macros, always surround each occurence of a parameter with a pair of parentheses, and surround the entire expression with another pair of parentheses, to make sure you get the precedences correct. -tom
jmc@inesc.UUCP (Miguel Casteleiro) (10/31/89)
In article <36899@srcsip.UUCP>, carpent@SRC.Honeywell.COM (Todd Carpenter) writes: > > [...] > As long as we are on the subject of Lattice, why doesn't this macro seem to > work? (I'm rather new to macrodom, so this is probably a silly one) I > have some terribly long nasty expressions that need to be squared, and > SQR(moocow) never returns what I expect: > > #define SQR(x) (x*x) This macro won't work if you have SQR(a+b), because the result will be a+b*a+b which is diferent from what you want: (a+b)*(a+b). So, try: #define SQR(x) ((x)*(x)) -- __ Miguel Casteleiro at __ /// INESC, Lisboa, Portugal. "I know exactly what I'm doing." \\\/// Only UUCP: ...!mcsun!inesc!jmc -- Famous last words \XX/ Amiga
gilham@csl.sri.com (Fred Gilham) (11/01/89)
| As long as we are on the subject of Lattice, why doesn't this macro seem to | work? (I'm rather new to macrodom, so this is probably a silly one) I | have some terribly long nasty expressions that need to be squared, and | SQR(moocow) never returns what I expect: | | #define SQR(x) (x*x) | probably because moocow gets evaluated twice, which I bet is not what you want! -Fred Gilham gilham@csl.sri.com
martin@enuxha.eas.asu.edu (Ross D. Martin) (11/01/89)
In article <36899@srcsip.UUCP>, carpent@SRC.Honeywell.COM (Todd Carpenter) writes: > > In other news, I can now use the optimizer (on certain modules), and can use > the 68881 library. This gives me up to a 20% performance increase over IEEE > libraries and nonoptimized compilation. I was thrilled, as I need every bit I > can get. I am also _very_ happy the Lattice is providing these upgrades free to > registered owners. I wonder if they will institute a maintenance program to > recoup some of their mailing costs? > I am also very happy with the upgrade. If they did want to recoup their mailing losses, the upgrade would be worth a nominal fee. > > As long as we are on the subject of Lattice, why doesn't this macro seem to > work? (I'm rather new to macrodom, so this is probably a silly one) I > have some terribly long nasty expressions that need to be squared, and > SQR(moocow) never returns what I expect: > > #define SQR(x) (x*x) I have not yet narrowed it down for sure, but I also had some code that worked under 5.02 (using standard math libraries) but now doesn't under 5.04 (using 68881 inline code). This code figures macros prominently, so this may be a new bug. Possibly... I have also not been able to get 5.04 to work with the -pr option (automatic generation of prototypes.) This also worked in 5.02 just fine. Can anyone confirm whether this is a bug? Even with a few bugs that were not there in 5.02, 5.04 is a major fix. It's great! Ross Martin agrgm@acvax.inre.asu.edu
gerry@dialogic.UUCP (Gerry Lachac) (11/01/89)
In article <112@inesc.UUCP> jmc@inesc.UUCP (Miguel Casteleiro) writes: >In article <36899@srcsip.UUCP>, carpent@SRC.Honeywell.COM (Todd Carpenter) writes: >> >> #define SQR(x) (x*x) > >This macro won't work if you have SQR(a+b), because the result will be >a+b*a+b which is diferent from what you want: (a+b)*(a+b). > >So, try: > >#define SQR(x) ((x)*(x)) Actually, this is a classic case of macro side-effect. This also will produce incorrect results. Take for example the following line of C code: z = SQR(a++); Now, this will actually become: z = ((a++)*(a++)); Which will not produce correct results in certain situations. If a=7 for example, then: a = 7; z = ((7)*(8)); /* variable 'a' now has the value of 9 */ The bottom line is to be aware of side-effects when using macros. -- uunet!dialogic!gerry | "Even a dead plant turns | Dialogic Corporation OR | over a new leaf | 129 Littleton Rd gerry@dialogic.UUCP | when the wind blows." | Parsippany, NJ 07054 | | (201)334-8450
thfisher@lion.waterloo.edu (Terry Fisher) (11/01/89)
In article <GILHAM.89Oct31100813@cassius.csl.sri.com> gilham@csl.sri.com (Fred Gilham) writes: > >| As long as we are on the subject of Lattice, why doesn't this macro seem to >| work? (I'm rather new to macrodom, so this is probably a silly one) I >| have some terribly long nasty expressions that need to be squared, and >| SQR(moocow) never returns what I expect: >| >| #define SQR(x) (x*x) >| > >probably because moocow gets evaluated twice, which I bet is not what >you want! The fact that the expression gets evaluated twice is only an optimization problem. The macro should be changed to #define SQR( x ) ((x) * (x) ) Consider the line SQR( 2+3 ). #define SQR( x ) (x * x ) causes the above to be substitued with 2+3*2+3 = 11 #define SQR( x ) ((x) * (x)) yields the expression (2+3)*(2+3) = 25 as desired. >-Fred Gilham gilham@csl.sri.com Terry Fisher thfisher@lion.uwaterloo.ca thfisher@lion.waterloo.edu {...}!watmath!lion!thfisher