API usage rant

If you have been following me recently (Facebook, Linked-in, Tweeter, etc) you probably are aware that I have been busy taking care of the building of my new house, my job and what not (not necessarily in this order ;).

Man, building a new place proved to be a huge time sink; since we've finally finished the main construction phase I expect to blog more often.

Ok, so lets start with a rant (I am really good ranting :))

Some time ago I was playing with one of my toy projects when I got an exception while adding a new entry into a dictionary. The exception was quite self explanatory about what had happened (from the point of view of the dictionary class implementer): a duplicate key was added (which,  according to the documentation, is explicitly prohibited).

Ok, I can live with that, it was my fault after all ;) My real issue is that the message would be much more helpful had it included the actual key value (of course you override ToString() method in all of your public classes, don't you ?).
Without this information I was forced to debug the code (of course I could catch the exception and print the key but then I'd be required to change my code just to find out what was happening) to figure out what the original exception could have told me.

To my understanding, one of the reasons for this is to avoid possible sensible information from leaking and, even though IMHO this is reasonable, it makes me think whether we could do it better. 

To me looks like the dictionary class developer (product owner, or whoever) was faced with the usual coast/benefit decision: make it easier, more convenient to use or make it suitable for use when sensible information is involved and he/she decided for the later.

When writing libraries I usually tend to making it easier to be used at the coast of a higher chance of developers misuse (or using it in a way that may shut then in their foots). I confess that I had never thought about this particular scenario but now I think it could be fixed (made more flexible) by allowing the user (in this case the developer) to decide what to expose in exceptions (through an enum, an interface, you name it) and choosing a safe default value.

What do you think?

Adriano

Free (open source) RAM disk for Windows (x86 / x64)

Hi


Have you ever had the need to perform some I/O intensive operation on a relative small set of files? I do, usually when I need to compile some application.

In order to speed up this operation I've recurred to the so called "RAM Disks", applications that takes part of your computer's main memory and pretends that it is an actual disk. As you can imagine read/write/etc (I/O) operations against this virtual disk are much faster than operations against your actual hard disks (be it a traditional magnetic HD or a shine new SSD).

In the past 3 years I've used at least 3 different solutions and was happy with none. My main complain is that most of them were not capable (or it was really clumsy/hard to accomplish) of creating RAM disks dynamically, i.e, one is required to create it at OS start up time. Since my needs are dynamic (I may need more disk space at some points in time during the day) it is really hard to come up with a disk size that work for me: choose a to big disk and I am wasting precious RAM space; create a disk that's to small and I may find myself facing "out of disk space" errors (then cleaning up some junk and restarting my build tasks).

Fortunately some time ago I stumbled upon a RAM disk implementation that allows me to mount and unmount disks dynamically! Since then my work flow has been much more smooth ;) The not so good side is that it is not very easy for the "not computer savvy" user.

Bottom line is: if you need a stable and flexible (but maybe not so easy to start with) RAM disk solution you can't go wrong with this one.

What's wrong with this code - fun with assembly : the answer

In the previous post I presented the following program and asked what was the problem with it:

int fact(int n)
{
    if (n == 1)
        return 1;
    else
        n = n * fact(n - 1);
}

int main(int argc, char *argv[])
{
     int n = argc > 1 ? atoi(argv[1]) : 5;
     int i = fact(n);
   
     return printf("fact(%d): %d", n, i);
}

As I said in the previous post, the problem itself is not so hard to find out: take a close look in line 6 again! We are not missing any instruction, or are we? Actually we are missing a return  so line 6 should really look like

return n * fact(n - 1);

i.e, the developer forgot to include the return.
Note that the compiler tried to alert me with the following warning, but as you know, I just ignored it :) (as I said in the previous post, you should never ignore compiler warnings)

c:\temp\fact.c(7) : warning C4715: 'fact' : not all control paths return a value

So the interesting question is: why this program works even when it is clear that it is missing a return? In order to answer this question we are going to dive into the assembly generated code for this program. To get the assembly code just type the following in a command line (assuming you have cl.exe in your path):

cl fact.c /Fa fact.asm

Even if you have little knowledge of assembly, please, bear with me; I'll try to explain the important parts. Also I've simplified both functions (fact and main) assembly code removing not important (to this discussion) bits.

MESSAGE DB 'Fact(%d): %d', 00H
fact:
 push ebp
 mov ebp, esp
 
 cmp dword ptr [ebp+8], 1
 jne next_fact
 mov eax, 1
 jmp finish
 
next_fact:
 mov eax, [ebp+8]
 sub eax, 1
 push eax
 call fact
 add esp, 4
 imul eax, [ebp + 8]
 mov [ebp+8], eax
 
finish:
 pop ebp
 ret
 
main:
 call fact
 add esp, 4
 mov _i$[ebp], eax
 mov ecx, _i$[ebp]
 push ecx
 mov edx, _n$[ebp]
 push edx
 push OFFSET MESSAGE
 call _printf
 add esp, 12
 mov esp, ebp
 pop ebp
 ret 0

PS: If you want to generate an assembly source with more - actually lots of - information from the original C program use the following command line arguments:

cl fact.c /Fa fact.asm /FAscu

First let have some simple facts:

• fact function code starts at line 2 and extends through line 22 (ret instruction).
• Argument n is stored at address [ebp + 8]
• main function starts at line 24 and extends through line 37.
• main calls fact function on line 25 (again, please note that for brevity/simplicity reasons I removed parts of the main function, so it became easier to understand).

Now that we have a high level view of the code lets dig a little deep into the fact function code (and on main function when appropriate).

Lines 3 and 4 represents the standard C function prologue; the first interesting instruction is the one at line 6 which compares n (remember, [ebp + 8]) with 1 branching to label next_fact (line 11) if they are not equal.

Starting at line 12 the code loads n into register eax subtracts one from it and calls itself recursively. When fact returns from a previous recursive call (line 16) the code calculates n times eax i.e, the compiler used eax register to return the calculated factorial from fact. We can confirm this behavior inspecting line 27 (inside main function) which assigns eax to local variable i after calling fact.

But just using eax register to pass the return value from fact is not enough; this program works (accidentally) only because the compiler used the same register eax to perform the calculations and to pass the return value.

So we can conclude that in this particular program, omitting the return statement renders an executable equivalent to the one that would be generated had the return statement be present.

Note that different compilers (or even different versions of the same compiler) may choose other registers to perform the calculations / pass return values from functions; actually I have found at least one version of CL (from Visual Studio 6) that used register ecx to perform the multiplication and eax to pass the return values (rendering an incorrect program).

Note also that even the same version of a compiler may generate different versions of the code (one that uses eax for both, calculations and for the return values and another that uses a different set of registers) depending on options such optimization, debug, etc.


Best

What's wrong with this code - fun with assembly

Since, I'm a bit busy to create new posts I decided to cheat, translating this post from my old (Portuguese) blog :)

Before we continue let me make this clear: finding the actual issue is not terrible hard (even though it took me some time and of course I'll keep the answer to a future post :); the interesting part is to figure it out why it works (or at least, why it works when compiled with some compilers).

Ok, so lets go. Take a look in the following program: 


This program accepts a number (command line) and calculates its factorial.

I came across it while I was corrigindo a programming assignment from one of my students (yep, 14 years ago I used to work as a professor teaching C, C++, assembly and the like).

At that time I used Borland C++ 3.0 to compile and to my astonishment it worked! Last time, when I tried to compile it with VC 6 I noticed a different behavior (the application produced a wrong result) but using Visual Studio 2010 I can reproduce the same behavior as when I first compiled it with Borland C++ 3.0; of course, the compiler generated some warnings which were promptly ignored!

Warning

To ignore compiler warnings is not such a smart idea and of course I'm not recommending you should do it! Pelo contrário; check all compiler warnings in your code and understand the reasons leading the compiler to complain.Do not assume that the compiler has bugs (after all, Select is not broken). If the conclusion is that the code generating the warning is legitimate I suggest you to try to change it, or, in the worst case, disable the specific warning (via #pragma warning) just in the parts of the code that is producing the warning.

int fat(int n)
{
    if (n == 1)
        return 1;
    else
        n = n * fat(n - 1);
}

int main(int argc, char *argv[])
{
     int n = argc > 1 ? atoi(argv[1]) : 5;
     int i = fat(n);
   
     return printf("Fat(%d): %d", n, i);
 }

Have you figured it out already?


See you!

Interfaces in IL

After a long period of silence, today I've something interesting (IMHO) (and the time to, of course :)) to post about.

Last night I was reading a book about MS IL (intermediate language) when suddenly I stumbled with an intriguing paragraph about interfaces. The "intriguing" part motivated me to write a sample application to test whenever that would be valid in C# or not.
Given the following NUnit test, how can you define a type "IAmAnInterface" so it can pass ?

 
using System;
using NUnit.Framework;

namespace Testing
{
 
 [TestFixture]
 public class BlobPost_Interface
 {
  [Test]
  public void Test()
  {
   var type = typeof(IAmAnInterface);
   Assert.That(type.IsInterface, Is.True);

   var field = type.GetField("fld");
   Console.WriteLine("    Field: {0}", field);
   Assert.That(field, Is.Not.Null);

   field.SetValue(null, 10);

   Assert.That(field.GetValue(null), Is.EqualTo(10));
  }
 }
}

Just in case you missed it, the crux here, is that the test expects IAmAnInterface to be an interface and (and here lies the issue) to define a (static) field! 

How come? An interface with fields?

Well, it happens that the C# specification (and the compiler also!) disallows such constructs, but they are actually valid in IL (as described in Common Language Infrastructure ,session 8.9.4)!

So, in order to get this to work I simply created an assembly in IL (actually I disassembled an assembly written in C# and changed it) that looks like:

.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         
  .ver 4:0:0:0
}
.assembly TestString
{
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilationRelaxationsAttribute::.ctor(int32) = ( 01 00 08 00 00 00 00 00 ) 
  .custom instance void [mscorlib]System.Runtime.CompilerServices.RuntimeCompatibilityAttribute::.ctor() = ( 01 00 01 00 54 02 16 57 72 61 70 4E 6F 6E 45 78   // ....T..WrapNonEx
                                                                                                             63 65 70 74 69 6F 6E 54 68 72 6F 77 73 01 )       // ceptionThrows.
  .hash algorithm 0x00008004
  .ver 0:0:0:0
}
.module TestString.dll
// MVID: {64C46A76-194E-4608-A835-B41B179AF4FA}
.imagebase 0x00400000
.file alignment 0x00000200
.stackreserve 0x00100000
.subsystem 0x0003       // WINDOWS_CUI
.corflags 0x00000001    //  ILONLY
// Image base: 0x004D0000


// =============== CLASS MEMBERS DECLARATION ===================

.class interface public abstract auto ansi IAmAnInterface
{
  .method public hidebysig newslot specialname abstract virtual 
          instance int32  get_value() cil managed
  {
  } // end of method IAmAnInterface::get_value
  
  .field public static int32 fld

} // end of class IAmAnInterface


// =============================================================

and referenced it in my C# test application inside VS2010 which happily showed the field in IntelliSense but gave an error when I tried to compile the code (so I resorted to reflection, and it worked) (see picture below):

What do you think?

Best

Adriano

Do as I say, not as I do

It has been a long time since my last post ...


As usual I have been busy taking care of my kids (if you have two kids you have an idea how much time they require :)), studying, playing with may pet projects and what not.


But something happened and motivated me to stay late and to write this post. To make a long history short, yesterday night I was working on one of my pet projects, binboo (basically a skype plugin that I and other team mates use to add/update issues on our bug tracker) and I spot some code that looked pretty useless to me.


Since I have unit tests (yeah, some of you would argue that strictly speeking they are not unit tests, but anyway, I have automated tests in place) I was not scared of changing the code, so in the next step I just removed the "dead" code running the tests after that. To my happiness, I saw only green in the unit test runner screen. 

Perfect, I though, proud of myself.

After that I just committed my changes and went (happy) to bed only to be embarrassed in our meeting today with an ugly, idiot, ridiculous bug in the exact same code I have touched yesterday. It became clear to me that my unit test coverage can be improved.


After my normal work day I just loaded the project in VS to look at the specific test case that should have failed due to my change but, to my surprise, I had no test case for this particular scenario. Hum... stupid developer.


Lesson learned, I have written a test case before reverting the changes (and of course, I'll study the code to understand why it is required after all).


Ok, let me get back to my other pet projects.


Have fun!


Adriano

What's wrong with this code (Part XII)

In the last post in this series ("what's wrong with this code") we discussed how db4o's reference system remembers which objects have been stored / retrieved.

In this post I'll show you another piece of code that doesn't always work as the developer expects:

class User
{
   public string Name;
   public User Manager;
   public IList Addresses;

   public User(string name, User manager)
   {
      Name = name;
      Manager = manager;
   }
}

class Address
{
   public string Street;

   public Address(string street)
   {
      Street = street;
   }
}  


using (var db = Db4oEmbedded.OpenFile(databaseFileName))
{
   List<Address> addrs = new List();
   addrs.Add(new Address("Street1"));
   addrs.Add(new Address("Street2"));
   User fooManager = new User("Foo") { Addresses = addrs };

   User fooBarManager = new User("FooBar", fooManager);
   User barManager = new User("John Doe",  fooBarManager);
   User user = new User("Adriano",  barManager);
    
   db.Store(user);
}

using (var db = Db4oEmbedded.OpenFile(databaseFileName))
{
   var query = db.Query();
   query.Constrain(typeof (User));
   query.Descend("Name").Constrain("Adriano");
   
   User user = (User) query.Execute()[0];
   Console.WriteLine(user.Manager.Manager.Manager.Addresses[0].Street);
}

Can you see the problem? No, I am not talking about Law of Demeter "violation" :) (By the way, if you are interested in this subject you can find a nice discussion here).

Again, if you have been working with db4o for some time I am sure you already spent some time debugging this kind of issue.

As always, the answer comes in a future post.

Have fun!

Adriano