I've just purchased a license for Deleaker by Softanics. I found out about the tool from Bartek's coding blog where he writes about the tool here.

I downloaded the trial edition and it found quite a few subtle issues in some of my unit test code. Nothing too serious, but stuff that other tools have missed. The run-time overhead doesn't appear to be that great, my server tests still run at a reasonable speed and nothing fails because of the instrumentation. My virus checker (Bitdefender) hates the tool, probably due to the code injection and whatever that's required. The developer is easy to talk to and interesting in dealing with any issues that you have.

The price is a little steep, but I got a decent discount for being a reader of Bartlomiej's blog and that helped. I'm not sure I would have purchased otherwise. At the discounted price it's a useful addition to my toolbox.

I've been trying various static analysis tools on the C++ code of The Server Framework. I've now been using Resharper C++ quite regularly for over a year and I still use the Gimpel PC-Lint Plus Beta on a regular basis. I haven't used CppDepend as much, mainly because once I'd fixed the issues that it raised, and that I decided I needed to fix, I pretty much left it alone. This is possibly because I run it as an external tool and I run both Resharper and PC-Lint as fully integrated Visual Studio extensions.

Full disclosure. I have been given another CppDepend license.

As I've said before, whilst CppDepend is easy to get hold of, easy to install and "just works" I don't find it that useful. I tried installing the Visual Studio add-in this time around and found that I then had problems removing the add-in. I've no idea why and it was probably just me, but I decided to stick with the stand-alone tool.

As I said last time, I can certainly remember large enterprise clients where this kind of tool would be invaluable for management level analysis of large codebases but for a small development team of competent people it's less immediately useful. It still fills some gaps so it's still useful to me; perhaps I need to try harder with the Visual Studio add-in.

There are some nice new features to this latest edition: Smart Technical Debt estimation looks like a good way of preventing a codebase degrading over time and helping you to focus on issues that can be fixed quickly, or issues that are really complex and will take ages to fix.... Being able to navigate to types with the most technical debt is useful. I also like the idea of the Quality Gates concept. The html reporting stuff also looks useful, though I'd have to get CppDepend running on my build servers as part of the build and release process to get the best benefit from it.

All in all I like the new features but I'm still not sure that I would purchase a license for this tool but I know clients that could benefit from using it.

Enabling FILE_SKIP_COMPLETION_PORT_ON_SUCCESS on a handle associated with an I/O completion port can improve performance and reduce context switching by allowing the thread that calls the API that can complete asynchronously to handle the completion "inline" if the call can complete synchronously. This is especially useful for TCP reads when there's already data in the network stack's buffers, or writes when there is space in the buffers. Whilst there are design issues that must be taken into consideration before simply enabling this flag (beware recursion!) there's a little known issue where code outside of your control can prevent the IOCP from operating correctly when this flag is enabled.

If non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) are installed then you may not receive completions at all for handles with the flag set.

This Microsoft Knowledge Base article has been around for quite a few years and it's important and possibly becoming more so as more and more poorly written LSPs get installed by adware and other rubbish.

It's all very well knowing that you can't use FILE_SKIP_COMPLETION_PORT_ON_SUCCESS when you have a non-IFS LSP installed but how can you tell at runtime that this is the case?

We've had this code in The Server Framework since 2011 or so: it iterates the Winsock catalog and lets you know if any non-IFS LSPs are installed. You can then use the results of this to determine if it's safe to enable FILE_SKIP_COMPLETION_PORT_ON_SUCCESS or not.

static const int s_protocols[] = { IPPROTO_TCP, IPPROTO_UDP, 0 };

bool CanEnableSkipCompletionPortOnSuccess()
{
   // At some point we MAY want to check for UDP and TCP transports separately,
   // if we do that then we need to change this.

   TExpandableBuffer<BYTE> buffer;

   LPWSAPROTOCOL_INFOW pProtocolInfo = nullptr;

   DWORD bufferLength = 0;

   int error = 0;

   int numEntries = ::WSCEnumProtocols(
      const_cast<int *>(&s_protocols[0]),
      pProtocolInfo,
      &bufferLength,
      &error);

   if (SOCKET_ERROR != numEntries)
   {
      throw CException(
         _T("CanEnableSkipCompletionPortOnSuccess()"),
         _T("Expected first call to fail and return buffer size!"));
   }

   int attempts = 0;

   bool done = false;

   while (!done)
   {
      if (error != WSAENOBUFS)
      {
         throw CWin32Exception(
            _T("CanEnableSkipCompletionPortOnSuccess()"),
            error);
      }

      if (attempts++ > 3)
      {
         // so the amount of memory required is always changing??

         throw CException(
            _T("CanEnableSkipCompletionPortOnSuccess()"),
            _T("Cannot allocate appropriate buffer: ") +
            ToString(bufferLength));
      }

      buffer.Resize(bufferLength);

      pProtocolInfo = reinterpret_cast<LPWSAPROTOCOL_INFOW>(buffer.GetBuffer());

      numEntries = ::WSCEnumProtocols(
         const_cast<int *>(&s_protocols[0]),
         pProtocolInfo,
         &bufferLength,
         &error);

      done = (SOCKET_ERROR != numEntries);
   }

   bool ok = true;

   for (int i = 0; ok && i < numEntries; ++i)
   {
      ok = ((pProtocolInfo[i].dwServiceFlags1 & XP1_IFS_HANDLES) == XP1_IFS_HANDLES);
   }

   return ok;
}

A bug has been discovered in Release 6.7 in the code that deals with TCP socket writes that involve more than a single buffer. These 'multi-buffer writes' are writes that involves either a buffer chain or a block of data passed as a pointer and a length where the length exceeds the size of the buffer allocator that the connection is using.

The bug prevents the 'multi-buffer write' from being executed as a single atomic write at the network layer and so can cause corruption of a TCP data stream if multiple sockets are writing to the same connection concurrently.

The bug is due to the removal in 6.7 of the code required to support Windows XP. In Windows XP we needed to include sequence numbers in write operations to allow for the way we always marshalled all I/O operations from the calling thread to an I/O thread to prevent I/O cancellation due to thread termination. This write sequencing code had the side effect of also protecting 'multi-buffer writes' from being interrupted by other writes.

The fix does not require the reintroduction of write sequencing but, instead, issues a single scatter/gather style write for the entire buffer chain. This is both efficient and correct.

A related bug also affects atomicity of 'multi-buffer writes' into filter layers, such as the SSL code. Similar fixes have been applied here.

The bug is fixed in Release 6.8 which will be released later today.

I've been looking at Resharper C++ by JetBrains for a while now and the trial period has finally run out. I immediately bought a license which shows how my feelings have changed about the product during the trial.