[9fans] test(1) -older bug?

[arisawa]

Hello,

How do you think?
I think test is buggy in "older" operation.
the test is from 9front. I have not tried bell-labs test.

term% ls -l
--rw-rw-r-- M 149 arisawa arisawa 3277 Apr 9 23:11 x
--rw-rw-r-- M 149 arisawa arisawa 4555 Apr 9 23:12 y
term% mtime x
1365516710 x
term% mtime y
1365516741 y
term% if(test x -ot y) echo OK
OK
term% if(test x -older 1365516741) echo OK
term% if(test x -older 1365516700) echo OK
term%
term% date -n
1370119926
term% dc
1370119926 1365516710 - p
4603216
term% if(test x -older 4603216) echo OK
OK
term% if(test x -older 4703216) echo OK
term%

term% man test
f -older t True if file f is older than (modified before)
time t. If t is a integer followed by the letters
y(years), M(months), d(days), h(hours),
m(minutes), or s(seconds), it represents current
time minus the specified time. If there is no
letter, it represents seconds since epoch. You
can also concatenate mixed units. For example,
3d12h means three days and twelve hours ago.

Kenji Arisawa

[erik quanstrom]

yup. i think it's a bug:

/n/sources/patch/older
/n/atom/patch/older

- erik

[c***@gmx.de]

its /n/sources/patch/testolder, also leaks dir in the case:

if(rel)
n = time(0) - n;
if(n < 0)
return 0; <----- HERE
r = dir->mtime < n;

free(dir);
return r;

--
cinap

[erik quanstrom]

Post by c***@gmx.de
if(rel)
n = time(0) - n;
if(n < 0)
return 0; <----- HERE
r = dir->mtime < n;
free(dir);
return r;

thanks. i appreciate the catch.

[sources] applied patch: /n/atom/patch/applied/testolder1

email
***@quanstro.net
readme
fix memory leak pointed out by cinap
removed

files
/sys/src/cmd/test.c test.c

/sys/src/cmd/test.c test.c
test.c.orig:373,380 - test.c:373,381
if(rel)
n = time(0) - n;
if(n < 0)
- return 0;
- r = dir->mtime < n;
+ r = 0;
+ else
+ r = dir->mtime < n;

free(dir);
return r;
------
merge...backup...copy...
cpfile test.c /n/dist/sys/src/cmd/test.c
done

[Richard Miller]

Post by c***@gmx.de
if(rel)
n = time(0) - n;
if(n < 0)
return 0; <----- HERE
r = dir->mtime < n;
free(dir);
return r;

And the consequences of not freeing a few bytes of memory, in a command
which will exit a few microseconds later, would be ... ?

[Jacob Todd]

Post by Richard Miller
And the consequences of not freeing a few bytes of memory, in a command
which will exit a few microseconds later, would be ... ?

bad taste.

[a***@skeeve.com]

Post by Richard Miller
And the consequences of not freeing a few bytes of memory, in a command
which will exit a few microseconds later, would be ... ?

The Code Correctness Police come and collect you and force you to
program on Windows... <ducks>

:-)

Arnold

[erik quanstrom]

Post by a***@skeeve.com

Post by Richard Miller
And the consequences of not freeing a few bytes of memory, in a command
which will exit a few microseconds later, would be ... ?

The Code Correctness Police come and collect you and force you to
program on Windows... <ducks>

excellent points. there is no consequence. but conversely, there is
no penalty for free'ing the memory either. given that, i prefer free'ing
the memory to be consistent with the rest of the source, and accept
cinap's bug as a bug.

of course you can say needless consistency is the hobgoblin of little
minds...

:-)

- erik

[Richard Miller]

bad taste.

I agree - better style is to free memory always, or never. But the
choice might not be as obvious as one first thinks.