🚀 go-pugleaf

In article <1416@ecicrl.ocunix.on.ca> clewis@ferret.ocunix.on.ca (Chris Lewis) writes:
>When compress tries to set the time on the file it's just
>created to be the same as the original file, things go a little
>awry.  The code is:
>
>	time_t timep[2];
>	...
>	timep[0] = statbuf.st_atime;
>	timep[1] = statbuf.st_mtime;
>	utime(ofname, timep);	/* Update last accessed and modified times */
>
>On the 88000, (as in 1003.1), timep is actually a struct.  All would be well,
>except on the 88000 they've inserted an additional time_t after the atime
>and the mtime field to contain microseconds....  So, what happens is that
>the atime is set properly, the atime usec field is set to mtime, and the mtime is
>set to garbage (the epoch due to the stack contents in my case).  I'm not sure
>whether this makes the OS/header file noncompliant with 1003.1.
>
>Looks to me that compress.c needs an ifdef so as to use the struct
>definition.

Yes, I would have preffered if the 88k BCS had specified the microsecond
fields after the second fields, ie:
  struct {
	time_t	actime;
	time_t	mtime;
	time_t	acusecs;
	time_t	musecs;
  };

Then it would be harmless to have the microsecond fields set to a random
value, although there would still be some possibility of reading beyond
allocated memory if the structure were at the very end of the data section.

Other notable programs to look out for:  archiving programs (specifically
pax, gnu tar, gnu ar) and a few game programs (one that update the time
of their score file and check it to see if hanky-panky is going on).

-- 
John Tamplin						Xavax
jat@xavax.COM						2104 West Ferry Way
...!uunet!xavax!jat					Huntsville, AL 35801