clewis@ferret.ocunix.on.ca (Chris Lewis) (04/19/91)
[Pardon the cross-post, but this seemed to be of interest to both the OS people and the language people] 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. (Motorola Delta 88000 system with Greenhills C compiler) -- Chris Lewis, Phone: (613) 832-0541, Internet: clewis@ferret.ocunix.on.ca UUCP: uunet!mitel!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
jat@xavax.com (John Tamplin) (05/01/91)
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
ggw@wolves.uucp (Gregory G. Woodbury) (05/01/91)
In <1991Apr30.180949.12824@xavax.com> jat@xavax.com (John Tamplin) writes: >In <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. > >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). Additionally, ELM and other mail packages that touch the times of the mailbox files are subject to problems. Elm, specifically will report that it could not properly adjust the time on the user mail box, when, in fact, it is correctly set. The OS reported an EINVALID error on the call which is a little strange. -- Gregory G. Woodbury @ The Wolves Den UNIX, Durham NC UUCP: ...dukcds!wolves!ggw ...mcnc!wolves!ggw [use the maps!] Domain: ggw@cds.duke.edu ggw%wolves@mcnc.mcnc.org [The line eater is a boojum snark! ] <standard disclaimers apply>