Language Lawyers (and Nasal Demons)

Friday, July 30, 2004 by scott
5 comments
As soon as a development language has an official specification behind it, the first language lawyer appears. If you’ve never seen one in action, they are the type who can rattle off section and paragraph numbers from a specification while explaining the bizarre behavior of some code snippet. You might see them write something along the lines of:

The values of a and b are automatically promoted back to int [6.2.1.1/ 3.2.1.1], which is then the type of the result of the / operator [6.2.1.5/3.2.1.5]. Since -32768 is exactly divisible by -1, and the result of 32768 is representable in the type int, the division must yield this value.

Nearly every language with a specification will describe situations with “undefined behavior”. Undefined behavior means there is something so horribly screwed up in the code, or in the data, that the program is probably going to crash spectacularly. Except specifications never use the word ‘crash’. Many of them, including the C# spec, will use the more dignified phrase: “unpredictable results”.

Now language lawyers, not really being lawyers, have a sense of humor. Since the phrase “unpredictable results” leaves the outcome so open-ended, they will say undefined behavior could, in fact, lead to demons flying out of your nostrils.

The first apparent reference to demons and noses came in a 1992 post to the comp.std.c newsgroup. The post contains many paragraph and section number references to the C language specification, but ends with this little gem:

In short, you can't use sizeof() on a structure whose elements haven't been defined, and if you do, demons may fly out of your nose.

The phrase caught on.

In the mid 90’s I was maintaining a C code base intended for both an 8 bit Hitachi chip and the PC, so I was interested in writing portable ANSI C programs and followed the comp.std.c and comp.lang.c newsgroups. I don’t know how many times someone would come along and post code which started like this:

void main (void)

As soon as the above line appeared the language lawyers appeared in force. You could look at the code, and see it was only one semi-colon away from curing world hunger, but it didn’t matter, because the response was invariably something like:

The Standard says that declaring main as returning void invokes undefined behavior. Beware the nasal demons.

Although sometimes the lawyers would make other amusing comments:

if you write:

void main (void) 

it's *possible* (under the rules of C) that your computer will pogo round the room whistling the star spangled banner. It's very unlikely, but C isn't interested in "likely".

Whenever I was having a really bad day, I’d write a program with main returning void just to see what would happen. I tried it with the Microsoft C compiler, the Borland C compiler, the Intel C compiler, and the now defunct Boston Systems Office C compiler. I was hoping to create a horrible, slimy demon who I could train to stand at my office door and terrify people trying to enter with requirements documentation in hand. Not only did I never get a demon, the programs always worked without any errors. Shows you what the language lawyers know.

In any case, I’m hoping to find some good examples of undefined behavior in C# or VB so I can try to invoke nasal demons from .NET. I imagine it will be much harder to do with a managed runtime in place, but if you know of any opportunities, please let me know.

Static Constructors Are Not Miracle Workers

Thursday, July 29, 2004 by scott
1 comment
The CLR guarantees a type initializer (static constructor) will execute only once for any given type. This simplifies my life, because I don’t need to worry about multiple threads inside of a static constructor. Take for example the following program:

static void Main(string[] args)
{
   Thread threadA = new Thread(new ThreadStart(TouchFoo));
   threadA.Name = "Thread A";
 
   Thread threadB = new Thread(new ThreadStart(TouchFoo));
   threadB.Name = "Thread B";
 
   threadA.Start();
   threadB.Start();
   
   threadA.Join();
   threadB.Join();
}
 
static void TouchFoo()
{
   Foo.SayHello();
}
 
class Foo
{
   static Foo()
   {
      Thread.Sleep(1000);
      Console.WriteLine("Foo .cctor on thread {0}", Thread.CurrentThread.Name);
   }
 
   static public void SayHello()
   {
      Console.WriteLine("Hello From Foo");
   }
}

In this program, Thread A will probably get the first chance to execute TouchFoo. In doing so, the CLR recognizes the static constructor for Foo has not been executed and sends Thread A into the constructor, which puts the thread to sleep for 1000 ms. The sleeping period allows Thread B to run. Thread B arrives inside of TouchFoo, and again the CLR recognizes the static constructor for Foo has not completed executing. This time however, the CLR knows somebody is working inside of the constructor, and it blocks Thread B until Thread A finishes Foo’s constructor. Typically then, this program would produce the following output:

Foo .cctor on thread Thread A
Hello From Foo on thread Thread A
Hello From Foo on thread Thread B

No matter how many threads we throw into the mix, the CLR will only allow one thread inside of the static constructor. Of course this isn’t magic, there has to be some thread synchronization (a lock) taken by the CLR before entering the static constructor.

Where there are locks, there is the possibility of a deadlock. So what happens if we try to put the runtime into a bind by feeding it code that should deadlock? Do you think the following program will execute, or will I need to kill it from task manager?

class Class1
{
   [STAThread]
   static void Main(string[] args)
   {
      Thread threadA = new Thread(new ThreadStart(TouchFoo));
      threadA.Name = "Thread A";
      
      Thread threadB = new Thread(new ThreadStart(TouchBar));
      threadB.Name = "Thread B";
 
      threadA.Start();
      threadB.Start();
 
      threadA.Join();
      threadB.Join();
   }
 
   static void TouchFoo()
   {
      string s = Foo.Message;
   }
 
   static void TouchBar()
   {
      string s = Bar.Message;
   }
}
 
class Foo
{
   static Foo()
   {
      Console.WriteLine("Begin Foo .cctor on thread {0}", Thread.CurrentThread.Name);
      Thread.Sleep(5000);
      Console.WriteLine("Foo has a message from Bar: {0}", Bar.Message);         
      message = "Hello From Foo";
      Console.WriteLine("Exit Foo .cctor on thread {0}", Thread.CurrentThread.Name);
   }
 
   static public string Message
   {
      get { return message; }
   }
 
   static string message = "blank";
}
 
class Bar
{
   static Bar()
   {
      Console.WriteLine("Begin Bar .cctor on thread {0}", Thread.CurrentThread.Name);
      Thread.Sleep(5000);
      Console.WriteLine("Bar has a message from Foo: {0}", Foo.Message);         
      message = "Hello From Bar";
      Console.WriteLine("Exit Bar .cctor on thread {0}", Thread.CurrentThread.Name);
   }
 
   static public string Message
   {
      get { return message; }
   }
 
   static string message = "empty";    
}

Notice in this example, the static constructor for Foo references Bar’s Message property, and vice versa. This produces the following scenario:

Thread A starts and eventually enters the static constructor for Foo. After a writing to the screen, the thread goes to sleep for 5000 ms. Thread B now has a chance to run and eventually enters the constructor for Bar, prints a message and goes to sleep.

Next, Thread A wakes up and finds it needs information from an un-initialized Bar, but it cannot run the constructor because Thread B has it locked. Thread B awakes and needs information from Foo, but it cannot run the Foo constructor because Thread A has it locked. Thread A needs the lock held by Thread B, and Thread B needs the lock held by Thread A. Classic deadlock!

As it turns out, the CLI specification addresses this issue in section 9.5.3.3 of Partition II, entitled “Races and Deadlocks”:

Type initialization alone shall not create a deadlock unless some code called from a type initializer (directly or indirectly) explicitly invokes blocking operations.

So if we don’t have a deadlock, what happens? Here is the output on my machine:

Begin Foo .cctor on thread Thread A
Begin Bar .cctor on thread Thread B
Bar has a message from Foo: blank
Exit Bar .cctor on thread Thread B
Foo has a message from Bar: Hello From Bar
Exit Foo .cctor on thread Thread A

The message Bar retrieves from Foo is “blank”, but Foo was supposed to initialize the message to “Hello From Foo”. The runtime allowed Thread B to reference Foo before Foo’s static constructor completed! It could have just as easily allowed Thread A to reference Bar before Bar’s static constructor completed, but by letting just one of the threads through, a lock became free and we avoid a deadlock. The runtime cannot perform miracles and let both the constructors run to completion.

The morale of the story is: never touch the static member of another type inside of a static constructor.

C++ programmers knew this was a bad scenario, although for slightly different reasons. See the C++ FAQ for the “static initialization order fiasco”. The punishment for C++ programmers who do this is to take a job at a fast food restaurant, but then hard-core C++ devs are pretty heavy handed (the topic for a future post).

Database Retirement

Tuesday, July 27, 2004 by scott
0 comments
I installed SQL Server 2005 Beta 2 last night. This morning I noticed something missing.

If the current bits hold true till RTM, then I will have to lament the disappearance of a dear friend.

Everyone called your design a disaster, but I have fond memories of your eccentricities. Your Order Details table taught me how to delimit identifiers with [ and ]. Your "Ten Most Expensive Products" stored procedure taught me SET ROWCOUNT.

A countless number of articles, books, and newsgroup postings contain the query SELECT * FROM EMPLOYEES – a tribute to your ubiquity. Now they will lie in archived ruins like the statue of Ozymandias.

Farewell Northwind!

FileVesionInfo

Tuesday, July 27, 2004 by scott
0 comments
Getting the version number of any managed / unmanaged DLL or executable in .NET 1.0, if I recall correctly, required some magic incantations with PInvoke.

I just discovered the FileVersionInfo class from System.Diagnostics:

FileVersionInfo versionInfo;
versionInfo = FileVersionInfo.GetVersionInfo(@"e:\win2003\system32\svchost.exe");
MessageBox.Show(versionInfo.ToString());

Notice the class overrides the ToString method to provide nicely formatted information:

File:             e:\win2003\system32\svchost.exe
InternalName:     svchost.exe
OriginalFilename: svchost.exe
FileVersion:      5.2.3790.0 (srv03_rtm.030324-2048)
FileDescription:  Generic Host Process for Win32 Services
Product:          Microsoft® Windows® Operating System
ProductVersion:   5.2.3790.0
Debug:            False
Patched:          False
PreRelease:       False
PrivateBuild:     False
SpecialBuild:     False
Language          English (United States)

Lookout Assembly Hell

Monday, July 26, 2004 by scott
3 comments
I decided to download and try Lookout, the search tool for Outlook (now a free download from Microsoft). I’m hesitant to give out the link, since, like Elvis, it seems to popup and then disappear, but recent sightings have the download at Lookout Software again.

After installation, Outlook greeted me with the following error:

Sorry!! It looks like another Outlook Plugin has installed an unofficial version of the Outlook libraries which breaks Lookout. Lookout will not be able to load. For more information, see this link: http://www.lookoutsoft.com/forums/topic.asp?topic_id=10

Unfortunately, the aforementioned link doesn’t offer many leads on why the problem occurs, nor how to work around it. I have a few COM add-ins loaded, including SpamBayes, some thingy MapPoint installed, and one I wrote myself in C# to redirect email to a web account. I was guessing my software was causing the problem.

I think the problem occurs because Lookout uses the primary interop assembly for Office XP, while the add-in I wrote uses the PIA for Office 2003. I opened my project in the IDE to see if I could get the two working together when all hell broke loose.

Each time I tried to do anything with the add-in project I wrote, Visual Studio crashed and sent an error report. After the error reporting finished, a dialog would appear to tell me updates are available which might fix my problem, and I was sent to the Office updates page. After installing updates, I could not even open Visual Studio without a crash, so I rebooted.

After rebooting, everything appeared to be back to normal, and Lookout started to work once I disabled my C# add-in. I decided this wasn’t a battle I wanted to fight, and scrubbed out every reference to my component from the registry. My add-in isn’t highly useful, but Lookout is fantastic.

Who Moved My Furniture? (Small Company Life)

Friday, July 23, 2004 by scott
2 comments
On January 31st 2001 the company I worked for closed the doors. A company near Philadelphia had bought all the rights to the software and intellectual property of the former company, and 4 of us were given the opportunity to work for them on a short term consulting basis, starting January 2nd. I had a lead on going to work for a startup company in the video game industry, but it was taking some time to pan out, so I prepared to spend 3 days a week in Philly.

I have to admit I had a bias against Philadelphia going in. When I was a just a young ‘un my parents would drive to Philly to visit an aunt. I have only one memory from these trips, and it goes like this: We are getting ready to go back home. My dad leaves the house to take luggage to the car. Several minutes later he reappears at the door, luggage still in hand, and announces: “somebody stole the car”.

As a kid, the fact that there were people in the world who stole other people’s cars came as a traumatic revelation to me. Based on this experience, and on seeing Eagle’s football games on TV, I hold a terrible stereotype that the city is full of thugs and car thieves. For the longest time I thought the “City Of Brotherly Love” was more of a sarcastic joke instead of a description, but I then I think how close Philadelphia is to the state of New Jersey, so maybe these sayings are all relative.

One morning we arrived at the new company from the hotel at the same time as a tractor trailer. By the time we walked up to the sidewalk the back doors of the trailer were opening. I peered inside, and lo and behold, there was the furniture I used to see every day at work. Suddenly it all came crashing down on top of me. The old company was gone. They new company had really bought everything. I wasn’t just at a client site for a few days. I was a 1099 employee with no office to call home.

Over the next few days we tried to tell people at the new company what great furniture they were getting. We assumed they would love it, because the cubicles they had were old, and small. By contrast, our former company had spared no expense on furniture. Yes, we had cubicles, but they were the nicest cubicles I have ever seen. Spacious, with lots of nooks and crannies for storage, built in lights, and low walls. I hate cubicles as much as the next person, but these were decent.

I have a feeling the employees there were apprehensive about the new cubicles because they didn’t offer as much privacy as they were used to. We knew at least one software developer there who snoozed in the afternoon, but unless you got in really close, which was hard to do, it was impossible to tell.

The lack of privacy at our old office was actually sort of funny, because you knew just a little bit about the lives of other people. It wasn’t eavesdropping you know, it was just hard not to hear conversations like this one from a fellow architect:

“Yes honey, I understand it is your sister’s family, but I’m not just giving them money to go grocery shopping. We’ve tried that before and they waste it. I’ll take them grocery shopping, and I’ll tell you right now, they won’t be buying shrimp and brand name cereal on my dime. If they want cereal they get the generic stuff from Walmart.”

Other people at the other company had a different definition of private matters than I do. One developer sent an email to the staff alias that read like the following (I’m not making this up):

“Does anyone know a good dermatologist in the area? I need to get something lanced.”

When this email hit the inbox, you could just hear it ripple threw the building. People would gasp, or chuckle, or choke on coffee. To this day we still refer to the guy with the nickname of “Lance”.

Seeing familiar furniture in the building only added to the odd feeling I had there. It is tough to adjust to a new corporate climate when you know you are not desperate enough to relocate and stay. For one thing, they took everything too seriously. I tried to spread some cheer by making their Laser Jet printers display random funny messages, but it took them weeks to notice.

During my three weeks in Philly I was amazed to see some of the sales people from our old company appearing at the new company for interviews. I thought this was interesting because the old company went out of business due to a lack of sales, but it didn’t surprise me, because I had learned that sales people have no shame….

A CEO and His BMW (Small Company Life)

Thursday, July 22, 2004 by scott
4 comments
Optimism is a primary trait of startup company CEOs. With all of the risk and obstacles involved in getting a company off the ground, they have to be optimistic. The type of optimism goes beyond “glass half full” optimism. I’ve worked with CEOs who, when spotting an empty glass sitting on the hot asphalt of a desert highway, will convince everyone nearby that a freak microburst of rain is inevitable, and the glass will be full any moment now.

I worked with one of these CEOs during the bubble years. He was a charismatic factory of entrepreneurial ideas. Once the big money came in from the venture capitalists, however, the collective wisdom of higher powers decided the company needed an experienced business person at the helm. We didn’t need optimism anymore, we needed execution. So we acquired a new CEO who was equipped with the people skills of an ostrich and completely devoid of creative ideas.

Actually, I take that back – he did have one idea I can remember. We were working with a customer who built on the Java platform and wanted to use some of our COM+ components. At one point he wandered into a common engineering area and asked if we could “SQL some data around” to provide integration. Other than this, I don’t remember him ever coming out of his office, except for the monthly company meetings.

The company meetings happened every month only because we had monthly layoffs. I suppose these meetings were meant to boost the company morale and assure us everything was under control. It was during one of these meetings when the CEO described layoffs as “a way to scrub the barnacles off the bottom of the boat”. I’ll leave it as an exercise for the reader to determine if these words contain any inspirational value, because it is a subjective call. I can only remember thinking what we really needed during these times was the unabashed optimism of old. Well, that and another $30 million.

During the course of a year we dwindled from a headcount of about 150 people to 12. Sometime near my last paycheck the day came for Mr. CEO to go. The word was getting around that he was packing up in his office. We saw him roll a chair out to his 2-door sports car. We saw him carry a desktop computer to the car. A crowd gathered to watch from afar. Another computer went out the door.

I remember reading once about a contest at a car dealership. The person who could guess the number of golf balls that would fit into an SUV would win the SUV. I’m sure this guy knew exactly how many golf balls fit into his car, because he was using every square centimeter of space. Next to go was a bookshelf. It was incredible to watch.

A mob mentality began to form, and we began to collectively speculate if we should start tearing the place apart and taking it home. Being a mostly civilized group though, I think we ultimately decided just to go out for lunch and celebrate the end of an era. Not that we really had a reason to celebrate, because our time was coming soon too, and by the end of the month the company would officially close the doors. I wasn’t allowed to take any office furniture with me when I left, but it wasn’t the last time I saw my desk….

by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!