On Mon, 2005-08-15 at 14:13 +0200, Yegor Yefremov wrote:
> Comment a accepted:
> 
> long get_uptime_in_sec(void)
> {
>       long ret;
>       struct sysinfo *info = 
>                       (struct sysinfo*)malloc(sizeof(struct sysinfo));
>       
>       if(sysinfo(info) < 0)
>       {
>               perror("Getting uptime");
>               return -1;
>       }
>       
>       ret = info->uptime;
>       free(info);
> 
>       return ret;
> }

Actually, I'd be inclined to do away with the dynamic allocation
altogether.  It would be much simpler (as well as more efficient)
to use a static data structure:

    long get_uptime_in_sec(void)
    {
        static struct sysinfo info;

        if (sysinfo(&info) < 0 ) {
            perror("getting uptime");
            return -1;
        }
        return info.uptime;
    }


> I just wanted to show the main concept, that the usage of uptime is
> safer and more precise then the usage of local time.

You may well be right.
But that does rely on there being some way of determining this
"uptime".   It's fairly clear that 'sysinfo' is Linux specific,
so is no use as a general-purpose mechanism.


However it looks as if we've already done this:

>                        But I think every architecture should
> offer the function to obtain the uptime. GetTickCount() under
> Windows for example.

The current version of the code uses 'times()', which returns
the uptime since an arbitrary point (typically when the system
booted).  This *is* portable, and should address your concerns.

This fix has been applied to the 5.1.x, 5.2.x and current
development lines.   Can you please try one of these versions,
and confirm whether the problem is still present.

Dave


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to