The clock() function

The ISO C standard specifies that

The clock function determines the processor time used.

It is clear that the result should be processor time instead of wall-clock time (real time).

It turns out that clock() in Microsoft C does return the wall-clock time instead of processor time.

I do understand Microsoft probably were not intentionally trying to violate the standard. It is meaningless to talk about processor time in DOS (nor does DOS provide any mechanism to measure processor time, afaik), and many programs used clock() to measure real time even if there were lots of system calls, disk accesses, etc. (which would make processor time significantly differ from real time in time-sharing systems). Probably Microsoft intended to maintain this “compatibility.” But is this really necessary? They could have corrected this either during the migration from single-task DOS to time-sharing Windows, or from 16-bit Windows 3 to 32-bit Windows 95/NT – just one more “incompatibility,” compared to other huge differences, not so important, was it?

Tags: C/C++, DOS, time, Windows

An Rvalue Reference Issue

I’m now convinced it was way too premature to try to take advantage of C++0x features (r-value references, etc.) in tiary (if the compiler supports).

With GCC 4.3.4, even the following innocent function leads to segmentation fault:

#include <string>
#include <utility>

std::string && my_move (std::string &str)
{
    std::string && tmp = std::move (str);
    return tmp;
}

In GCC 4.4, this function simply casts the non-const lvalue-reference parameter to an r-value reference and returns it, which I think is correct. In 4.3, however, tmp refers to a temporary object on stack, move-constructed from str.

Then I replaced std::string with std::list<int> and tried again. This time, GCC (4.3.4) itself segfaults. Ooops..

Tags: C++0x, C/C++, GCC, segfault

DHCPNAK

The following is extracted from my system log file:

Nov 1 11:53:24 laptop dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Nov 1 11:53:24 laptop dhclient: DHCPNAK from 192.168.1.1
Nov 1 11:53:25 laptop dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Nov 1 11:53:25 laptop dhclient: DHCPOFFER from 192.168.1.1
Nov 1 11:53:25 laptop dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Nov 1 11:53:25 laptop dhclient: DHCPACK from 192.168.1.1
Nov 1 11:53:25 laptop dhclient: bound to 192.168.1.3 — renewal in 39303 seconds.

Apparently, my computer tried to renew the IP address from the router, and was rejected. Then my computer started over a new DHCP request, and was offered the same IP.

I found all renewal requests were denied after checking the logs back a few days. I wonder if the router was designed to deny any DHCPREQUEST unless it immediately follows a DHCPOFFER. I can’t figure out any good reason for this. What I could think of is that the firmware programmers were just too lazy to implement a good DHCP server – after all, it was the cheapest wireless router I was able to find…

Tags: DHCP, network