Bobulate

Consider the following snippet of C code:

write(1, "foo", 3);
write(1, "bar", 3);
write(1, "", 0); write(1, "", 0);
write(1, "moose", 4);

You expect to get 10 bytes on stdout like this (“foobarmoos”). The 0-byte writes are no-ops. In OpenSolaris, though, we’ve had a long-standing bug in Konsole that makes it hang sometimes. Well, not hang per se, it just ignores all subsequent output from the shell. It took some time before we discovered that it wasn’t hanging, just ignoring output and that you could still interact with the shell (e.g. type “exit”) to recover somewhat.

Various attempts at a fix have been tried. There are two hacks in kdelibs kpty library right now that attempt to address the problem. One accounts for FIONREAD returning 0 bytes available to be read and the other pushes two streams modules on to the terminal. The former doesn’t catch all the cases that block further output, and the latter breaks terminal size setting, which is terribly annoying. Most things assume 80×24 when TIOCGWINSZ fails.

But the basic assumption is that when FIONREAD indicates that there is data available from the terminal, that read() will always return more than 0 bytes and that 0 bytes indicates an end-of-file situation. Testing (and it’s annoying testing, driven from an xterm-only failsafe login with twm) indicates that 0-byte writes drop 0-byte chunks into the stream that kpty sees — a typical sequence is this: FIONREAD returns 10; read() returns 6 bytes (“foobar”); read() returns 0; read() returns 0; read() returns 4. Those two 0-byte reads correspond to the 0-byte writes in the stream, and they tell kpty to close the stream, which in turn stops output from reaching konsole.

I suppose the Linux and FreeBSD terminal subsystems suppress these 0-byte writes; I really don’t know why Solaris does amalgamate non-zero writes (e.g. “foo” followed by “bar” arrives as “foobar”) but keeps 0-byte writes on their own. Maybe it’s a matter of “don’t do 0-byte writes”, but experience shows that 0-byte writes happen all the time, in error messages, when hitting ^C in the shell, and other situations. So on Solaris at least, kpty needs to be armoured against them.

I’m building an updated kdelibs package now, it will hit the package server repo on bionicmutton later today, and I pushed the changes — also with some other Solaris corner cases — into KDE SVN for KDE 4.6 later. It feels good to sit down and finally ferret out a fix.

Sun Studio has been renamed Solaris Studio, to reflect its target OS — or maybe just to say that Sun has been consumed by the boa constrictor that is Oracle. Of course, Studio works on Linux as well, so the name is now a misnomer in other ways.

Solaris Studio 12.2 is out, a minor upgrade over 12.1. The KDE4 on OpenSolaris project is one of the biggest public consumers of the C++ compiler — I suppose VirtualBox is as well, although that project never led to much C++ technology being updated in Solaris. Pavel was active during the beta phase of this product, and was the first person to report a regression in the C++ compiler: the -Y flag (in particular, -YP, which is documented to prepend directories to the linker’s search path) changed behavior. Now, historically the -YP flag has been different between the C and C++ compilers (duh?), and code consolidation pushed the C behavior into C++.

Unfortunately, the documentation hasn’t been updated to reflect this change. Neither has the regression been fixed. In other words, a bug reported pretty much on day 1 of the beta, shipped unchanged three months later.

We (as in the KDE4 on OpenSolaris crew) are creative enough to adapt to this situation: instead of using -YP to prepend paths, we can set the whole search path (like we would in C) like so: -YP,/opt/kde4/lib:/usr/lib . There’s one big gotcha, though: the C++ runtime and standard libraries live in the compiler installation directory, which must be searched for them. So we end up with a situation like this: if it’s Studio 12.1, use -YP,/opt/kde4/lib (nothing else, since the compiler libraries and /usr/lib are searched already) and if it’s Studio 12.2, first find out where the compiler libraries are installed (typically, but not necessarily, /opt/solstudio12.2) and then use -YP,/opt/kde4/lib:/usr/lib:/opt/solstudio12.2/lib . And don’t forget to adjust for different architectures (x86 vs amd64 vs SPARC).

In short: Solaris Studio 12.2, don’t bother.

Of course, a compiler isn’t the most important thing for Oracle. That’s just enabling technology and I imagine that it just needs to be good enough to push their in-house code to production. ISVs apparently don’t contribute enough to the bottom line to give them the tools to use the OS as well.