News and 3-d logic solver

I have set up a news feed so that you can track changes on my web site. Today's news: solver for the 3-D logic game.

DTrace and C++

Solaris DTrace isn't that C++ friendly. The SDT provider doesn't work with C++ programs. But I have fortunately managed to find a workaround. Not pretty, but it works.

OOXML vs. ODF

Do I care whether OOXML becomes standardized? I don't. Why - because I think that it's basically a mistake to standardize a format that conflates presentation and content. In that respect, standardizing ODF was also a mistake. So I don't pretty much care if another such format is standardized. After discussing the issue a bit over a coffe with a friend, I said that they should have better standardized LaTeX. It seems that I'm not the only one who thinks so.

Spam, viruses and addressbooks

How do you know that someone has added your otherwise unpublished email address to their addressbook(s)? Of course, you suddenly start getting spam! I strongly suspect that there exist viruses/trojans whose only task is to steal data from your addressbook and send it away to .. (someone).

Linus on volatile

I'm referring to this thread on kerneltrap.org, where Linus is cited to be saying:
- in other words, the *only* possible meaning for "volatile" is a purely
single-CPU meaning. And if you only have a single CPU involved in the
process, the "volatile" is by definition pointless (because even
without a volatile, the compiler is required to make the C code appear
consistent as far as a single CPU is concerned).

He's absolutely wrong in his statement here (namely, that volatile is "by definition" pointless for a single CPU). The C99 standard says that any access to volatile object is a side-effect. This does not mean that compiler optimizations are effectively disabled; rather it means that the compiler must generate memory access instruction instead of caching the value in the register. [This is because accesses to volatile objects may produce side-effects, so the read value may change between reads without an intervening store instruction.]

Now, consider the following simple code in a uniprocessor configuration:

while(!flag) ;

which simply waits for the flag to become true (e.g. set by an interrupt handler). If flag is not declared as volatile, the compiler might well generate an infinite loop, but if the flag is declared as volatile, the compiler must generate code that will check the physical memory location in every iteration and thus the flag change from an interrupt handler will be detected.

So, volatile is important even on uniprocessors whenever there is a possibility of executing asynchronous code (e.g. interrupts). And its semantics is defined well enough to prevent errors like the one I have described above.

Oh well, I don't really care nor shall I bother to comment on this on the kernel mailing list. It's his kernel, I use it only on my desktop and I don't really care what future impact this change will have (and it might have far-reaching consequences that are really hard to discover; as any bugs related to asynchronicity). I have said long time ago that I'd never consider Linux for "serious" applications (i.e. anything else than a cheap desktop), and such displays of blatant ignorance by its leading developer just make my stand firmer.