gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/08/88)
In article <10068@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >Yes. I was shocked when I read that abs() was taken out of <math.h> and >more so when I read the reason. abs() was removed from <math.h> because >some compilers will create executable images with unused floating point >routines in them <math.h> is included. > >Flame on: Of all the stupid things I read in the draft this takes the >cake. Why don't the vendors fix their stupid compilers and leave the ><math.h> users alone! Come on! abs() is a math function and <math.h> >is where it belongs! Well, if <math.h> is where it belongs, why isn't it there on UNIX systems? All you have uncovered is an error in the Rationale document. abs() was never in <math.h>, not in UNIX and not in the /usr/group 1984 Standard which served as the base document for the library. I will ask the Rationale editor to correct his document. P.S. I don't know of anybody who uses the abs() library routine; we all use a macro instead. I would be happy if abs() were not required at all.
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (04/09/88)
In article <7629@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <10068@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: > Well, if <math.h> is where it belongs, why isn't it there on UNIX > systems? Well, it should be. There are plenty of examples of missing "things" on UNIX systems that saying "Why isn't it there" doesn't mean much. For example, there is a system call (whose name escapes me - perhaps it's times()) that fills in a structure that looks something like: struct something_or_other { time_t tm_ctime; time_t tm_mtime; }; (the names are probably wrong). Anyway, the point is this struct is not declared in a header file anywhere in UNIX, it should be though. Lint makes a lot of noise about type conflicts when you use this struct, (hey ATT-IS, fix this!) > All you have uncovered is an error in the Rationale document. > abs() was never in <math.h>, not in UNIX and not in the /usr/group > 1984 Standard which served as the base document for the library. > > I will ask the Rationale editor to correct his document. Thank you. > P.S. I don't know of anybody who uses the abs() library routine; > we all use a macro instead. I would be happy if abs() were not > required at all. Likewise. My main gripe was that the standard was going to change an "existing" header file to cater to vendors. Since abs() is not in <math.h> there isn't much to say. We could argue about putting it in, but I'd just as soon not. -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)
chris@mimsy.UUCP (Chris Torek) (04/09/88)
>In article <7629@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: >>Well, if <math.h> is where [abs] belongs, why isn't it there on UNIX >>systems? In article <10170@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >Well, it should be. It *would* make sense. abs() tends to be defined in many places (with luck the definitions are all the same :-) ), but it is certainly a `common mathematical function' and hence <math.h> would be a reasonable place to stick a definition. Your argument about the utimes() syscall is incorrect, though: >For example, there is a system call ... that fills in a structure >that looks something like: > > struct something_or_other { > time_t tm_ctime; > time_t tm_mtime; > }; > >(the names are probably wrong). Anyway, the point is this struct >is not declared in a header file anywhere in UNIX, it should be though. The general idea is utimes(path, times) char *path; time_t times[2]; /* later BSD: char *path; struct timeval times[2]; */ ---i.e., it reads two objects of type time_t (struct timeval resp.), so you should pass it the address of the first element of a two-element pair of such objects that are members of an array. A common programming goof was to write struct stat st; int err = utimes("path", &st.st_atime); This did not work in 4.2BSD because the st_atime and st_mtime fields were farther apart than they were in V7 through 4.1BSD (there is a `spare' after each st_?time field in preparation for expanding the time stamps to 64 bits). >Lint makes a lot of noise about type conflicts when you use this >struct ... Good. (Aside to Nevin Liber: see, I can argue *against* bad-but-common programming practises too :-) ) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) (04/10/88)
In article <10992@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > > Your argument about the utimes() syscall is incorrect, though: > These are the definitions I had in mind when I wrote the previous note: struct utimbuf /* used in some system call */ { time_t actime; time_t modtime; }; union semun /* used with semaphore stuff */ { int val; struct semid_ds *sembuf; ushort *array; }; They aren't in any standard UNIX System V Release 2 header file on my 3B5 or 3B15. -- Larry Cipriani, AT&T Network Systems and Ohio State University Domain: lvc@tut.cis.ohio-state.edu Path: ...!cbosgd!osu-cis!tut.cis.ohio-state.edu!lvc (weird but right)
karl@haddock.ISC.COM (Karl Heuer) (04/11/88)
In article <10171@tut.cis.ohio-state.edu> lvc@tut.cis.ohio-state.edu (Lawrence V. Cipriani) writes: >In article <3377@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes: >> I just checked two systems (one BSD, one USGish), and neither declares the >> abs() function in any header. (Why should they? The default declaration >> suffices.$) > >What default declaration suffices for what? The argument types need to >be declared with a function prototype. I could live without abs() being >in <math.h> as long as it was in *some* header files. The default declaration, "extern int abs();", which is automatically generated by the compiler for any function which is used without a declaration in scope, suffices on the two systems I mentioned, because (having no ANSI compiler nor any other notion of prototypes) it conveys the same information as an explicit declaration. With ANSI C, the declaration becomes useful (assuming you find automatic argument type conversion useful) and indeed it has an associated header (as do all standard functions). Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint