Re: gethrxtime: fall back on gettime?

2005-11-12 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: Assuming someone cares about the affected systems, I'd be happy to let them do it. But in the meantime, everyone else who wanted to run on mingw would be left high and dry, as coreutils wouldn't build. Is there

Re: gethrxtime: fall back on gettime?

2005-11-11 Thread Jim Meyering
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: What do you think of making gethrxtime fall back on gettime? Yes, that makes sense to me. I installed the patch below. This also fixes the comments to match the code. Looks fine. Thanks! While we're

Re: gethrxtime: fall back on gettime?

2005-11-11 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes: Assuming someone cares about the affected systems, I'd be happy to let them do it. But in the meantime, everyone else who wanted to run on mingw would be left high and dry, as coreutils wouldn't build. Is there some middle ground here, where we can

gethrxtime: fall back on gettime?

2005-11-10 Thread Jim Meyering
Hi Paul, What do you think of making gethrxtime fall back on gettime? Currently, if it can't find a monotonic timer, it tries gettimeofday, then resorts to using time. Those are also the last resorts of gettime. The difference is that if gethrxtime used gettime, it'd benefit by using nanotime

Re: gethrxtime: fall back on gettime?

2005-11-10 Thread Paul Eggert
Jim Meyering [EMAIL PROTECTED] writes: What do you think of making gethrxtime fall back on gettime? Yes, that makes sense to me. I installed the patch below. This also fixes the comments to match the code. While we're on the subject, how about removing gettime's use of time