Nat!'s Web Journal

I think this could be worded in much more explecitive and redundant way, still giving away as little information as possible:

%@!!! The %@ preferences pane could not be removed because a %@ error occurred. Something apparently has gone %@ wrong. Expect that the %@ preferences pane is still there, because the removal attempt was interrupted by that %@ error. OK ??

One of the main arguments for zero filling is security. On a multi-user system you enter your password, which invariably is then stored if even temporarily in RAM. A clever process of a different user could now eventually swap in the used memory with this password and you are as they say compromised. (There is also an argument for it in a single user situation, I ignore this for this entry)

The same problem happens to an extent with hyperthreading. The fix for that appears to be, that hyperthreads are only allowed for processes of the same user. The same reasoning could be applied to memory as well. If memory is returned to the OS, then it need not be zeroed out if the owning process of the next allocation is by the same user.

This would make things quite a bit faster in some cases.

static void	BuildDeviceMenu(AudioDeviceList *devlist, NSPopUpButton *menu, AudioDeviceID initSel)
{
   [menu removeAllItems];
   
   AudioDeviceList::DeviceList &thelist = devlist->GetList();
   int index = 0;
   for (AudioDeviceList::DeviceList::iterator i = thelist.begin(); i != thelist.end(); ++i, ++index) {
      while([menu itemWithTitle:[NSString stringWithCString: (*i).mName]] != nil) {
         strcat((*i).mName, " ");
      }
      
      if([menu itemWithTitle:[NSString stringWithCString: (*i).mName]] == nil) {
         [menu insertItemWithTitle: [NSString stringWithCString: (*i).mName] atIndex:index];
         
         if (initSel == (*i).mID)
            [menu selectItemAtIndex: index];
      }
   }
}