Path: utzoo!mnetor!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: abs(), utimes()
Message-ID: <10992@mimsy.UUCP>
Date: 9 Apr 88 06:40:06 GMT
References: <7794@alice.UUCP> <10068@tut.cis.ohio-state.edu> <7629@brl-smoke.ARPA> <10170@tut.cis.ohio-state.edu>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 55

>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