utime & utimes & POSIX & portability

utime & utimes & POSIX & portability

Post by Stephen R. van den Be » Fri, 15 Nov 1991 23:50:44



I look in the manuals on SunOS, and I see something like this:

#include <utime.h>
int utime(path, times) struct utimbuf *times;

AND

#include <sys/types.h>
int utimes(file, tvp) struct timeval *tvp;

Now I was wondering, which one is the POSIX way to do it?  (utime ?)
What is the accompanying POSIX include file?
What is the OLD way of doing it?  (utime ?)

Are there systems which don't have one or the other?
Are the include files sometimes different?
Is there a biggest common denominator?

YAPI (Yet Another Portability Issue).

Thanks.
--


"-- Listen carefully, I shall say this only once --"

 
 
 

utime & utimes & POSIX & portability

Post by Guy Harr » Sun, 17 Nov 1991 06:57:45


Quote:>Now I was wondering, which one is the POSIX way to do it?  (utime ?)

Yes, "utime()" is the POSIX way of doing it.

Quote:>What is the accompanying POSIX include file?

<utime.h>.

Quote:>What is the OLD way of doing it?  (utime ?)

Yes - although the *really* old way of doing it (V7), isn't quite the
same as the POSIX way.  Originally, "utime" took a "time_t *" (or maybe
a "long *", I don't have V7 documentation handy) as its second argument;
it pointed to the first member of an array of two times, the first
member of which was the value for the access time, and the second member
of which was the value for the modification time.

In either S3 or S5 (I don't have S3 documentation handy, either), AT&T
introduced "struct utimbuf", which, on most if not all implementations,
had the same layout in memory as the aforementioned array.

One advantage of this is that code that passes a pointer to the
"st_atime" member of a "stat" structure as the second argument of
"utime()" will not pass "lint" (you *do*, of course, run your code
through "lint", right?).  This is an advantage because that code will
fail miserably on systems with BSD-style "stat" structures, because the
"st_atime" and "st_mtime" fields aren't contiguous.

One such system, BTW, is called System V Release 4....

(Note that the S3 "stat" manual page did *not* specify the layout of the
"stat" structure in memory; it just listed a set of fields that were in
the "stat" structure.)

They didn't introduce the <utime.h> header file, though, alas; that, I
think, was a POSIX invention.

Quote:>Are there systems which don't have one or the other?

I know of no modern UNIX systems that don't have "utime()" (where
"modern" means "V7 or later").  There *are* many systems that don't have
"utimes()", however.

Quote:>Are the include files sometimes different?

Yes - on some systems, the <utime.h> file contains

        /usr/include/utime.h: No such file or directory

or, at least, that's what "cat" said when I tried to print it. :-) :-)
:-) :-)

(I.e., the include file is *missing* on some systems.)

Quote:>Is there a biggest common denominator?

I don't know of anything that should work on all UNIX systems *and* on
all POSIX-conforming systems.  On most if not all UNIX systems, you
should be able to declare

        struct utimbuf {
                time_t  actime;
                time_t  modtime;
        };

and pass a "struct utimbuf *" as the second argument to "utime()".

*However*, that's not guaranteed to work on a *non*-UNIX
POSIX-conforming system (and there are vendors who are either offering
such systems now or claim they will be offering such systems in the
future); those other systems might lay out the "struct utimbuf"
structure differently.

Most, if not all, of them probably cannot safely *add* members to that
structure, for reasons that should be obvious (but apparently *weren't*
obvious to the 88open folk, alas, when they did the BCS), and none of
them can safely *subtract* members, so the worst that would happen is
that they might reverse the order of the two members.  This means you
can *probably* get away with the aforementioned declaration.