Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!ames!lll-lcc!well!msudoc!umich!jtr485
From: jtr485@umich.UUCP
Newsgroups: comp.lang.c
Subject: Re: fabs(x) vs. (x) < 0 ? -(x) : (x)
Message-ID: <68@umich.UUCP>
Date: Wed, 4-Feb-87 17:22:08 EST
Article-I.D.: umich.68
Posted: Wed Feb  4 17:22:08 1987
Date-Received: Sun, 8-Feb-87 05:45:59 EST
References: <4943@mimsy.UUCP> <2550005@hpisod2.HP> <628@sdchema.sdchem.UUCP>
Organization: EECS, University of Michigan
Lines: 25

In article <628@sdchema.sdchem.UUCP>, tps@sdchem.UUCP (Tom Stockfisch) writes:
> >You could implement fabs() as a macro as follows:
> >    #define fabs(X)     ((_fabs = (X)), (_fabs < 0? -_fabs : _fabs))
> >if _fabs were declared as a float in the math library.
> This might not work for
> 	fabs( x ) + fabs( y )
> because _fabs gets assigned twice in one expression and the two
> comma expressions which result might get interleaved.  There was
> a major discussion in this group recently on whether the sub-expressions
> a,b,c,d in
> 	(a,b) + (c,d)
> could be evaluated in the order
> 	a c b d
> Since the current defacto standard (K&R) is ambiguous on this point, I
> think your method is not safe.
> || Tom Stockfisch, UCSD Chemistry	tps%chem@sdcsvax.UCSD

This fixes that objection:

#define fabs(X)     (((_fabs = (X)) < 0? -_fabs : _fabs))

Again it requires the 'hidden' definition of _fabs but it does not have
order of evaluation problems.

--j.a.tainter