On Sun, 18 Jul 1999, Gerard Roudier wrote:
> I just found the following change in the ncr53c8xx driver:
>
> + if (lp && time_before_eq(lp->tags_stime + 3*HZ, jiffies)) {
> - if (lp && lp->tags_stime + (3*HZ) <= jiffies) {
>
> I do prefer a known bug that such a _not_ needed ambiguous construct, for
> the reason that, each time the arguments of time_before_eq() are
> _unfortunately_ in the reverse order we just get the opposite effect.
[i did not do that change, but] i personally do not find it hard to read.
It's the same, standard two-argument operator thing we use in many other
cases, like memcpy():
operator(x,y) := x operator y
in the above case:
time_before_eq(x,y) == x time_before_eq y
ie. 'x is before or equal to y'. What we'd like to have is an overloaded
'<' and '==' operator for time-type - but it's not that hard in C via
using function-syntax either. Just like memcpy(x,y) is easier to read via
an overloaded assignment operator, but it's not that hard to not mess it
up in it's current form either.
> The constructs I would have accepted looks like the following, for
> example:
>
> Either,
> + if (lp && time_before_jiffies_eq(lp->tags_stime + 3*HZ)) {
> Or,
> + if (lp && not_in_the_future(lp->tags_stime + 3*HZ)) {
>
> (And define appropriate macros if needed)
i agree, such things makes it more readable. The two fundamental operators
are:
in_the_future()
now()
in_the_past(x) := !now(x) && !in_the_future(x)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
