Pluralsight FREE Week

Just a heads-up to let you know that Pluralsight’s platform is FREE for the entire week!

You can watch 7,000+ expert-led video courses for free for one week only.

For example: Are you interested in an Introduction to Algorithms and Data Structures in C++? You can watch my course for free during this week!

Introducing the stack with an interesting metaphor
Big-O doesn’t have to be boring!

Or do you want to get started with the C programming language? No problem! I’ve got you covered.

Analyzing a subtle bug.
Analyzing a subtle bug.
Discussing the memory layout of strings in C.
Discussing the memory layout of strings in C.

These are just two examples.

But you can enjoy watching whatever you want from the entire Pluralsight library for free during this week!

Click the banner below and enjoy learning!

Pluralsight FREE Weekend

Just a heads up to let you know that Pluralsight is offering all its video courses, interactive courses and projects free from 8/13 to 8/15.

Happy Learning!

Limited-Time Offer: Pluralsight 33% Off Annual Standard and Premium Subscriptions

First, I’d like to express my gratitude to all the new Pluralsight learners who watched my courses during #FreeApril: Thank you all very much!

In addition, I just wanted to give you a heads-up that Pluralsight is offering 33% off Annual Standard and Premium subscriptions for a limited time.

EDIT 2021/05/11: The offer will end soon:  only 3 days left! Offer expires 5/13 at 11:59pm MT.

Click the banner below to save now!

Fixing the string_view-and-the-Magic-String Bug

In a previous blog post we saw an interesting and subtle bug involving std::string_view.

So, how can you fix that bug?

Well, an option could be creating a std::string instance from the string_view, and then invoke the string::c_str() method to pass a properly null-terminated string to the legacy C API:

void DoSomething(std::string_view name)
{
    // BUG:
    //   SomeCApi(name.data());
    //
    // FIX:
    SomeCApi(std::string{ name.data(), name.length() }
             .c_str());
}

In fact, string::c_str() guarantees that the returned string is null-terminated.

So, you may think to implement a simple inline helper function, to abstract away the previous ugly code:

inline const char* StringViewToCApi(std::string_view sv)
{
    return std::string{ sv.data(), sv.length() }.c_str();
}

But, if you try it out, you get the following output:

Weird characters are printed out instead of “Connie”.
Weird characters are printed out instead of “Connie”.

So, it looks like this time the cure is worse than the disease!

You got those weird characters instead of the expected “Connie”!

What’s going on here?

Well, if you take a look at your code in the Visual Studio IDE, you’ll note that the offending line is properly squiggled; and if you hover over that line with the mouse cursor, you get an interesting and clear explanation:

“The pointer is dangling because it points at a temporary instance which was destroyed.”

The Visual Studio 2019 IDE clearly diagnosed the problem in that code.
The Visual Studio 2019 IDE clearly diagnosed the problem in that code.

Basically, you created a temporary std::string instance inside the helper function, and then you invoked c_str() on it. The string::c_str() method returns a pointer to the temporary string object, which gets destroyed at the end of the helper function. As a result of that, the pointer returned back to the caller is dangling, as it points to some memory that has been already freed!

In fact, those box drawing characters showed in the output correspond to a 0xCC byte sequence, which is used by the Microsoft Visual C++ compiler to mark this kind of “invalid” memory.

So, how can you fix this bug?

Well, unfortunately, you just cannot safely return a const char* pointer that was handed to you by string::c_str(), if that string object was destroyed when the function exited.

However, what you can do is to simplify the above code, using a proper std::string constructor, that simply takes a string_view as input, and creates a std::string instance from the input string_view:

void DoSomething(std::string_view name)
{
    // BUG: SomeCApi(name.data());
    //
    // FIX:
    //
    SomeCApi(std::string{ name }.c_str());
}

And, finally, you get the expected output!

The expected output is printed out using the fixed code.
The expected output is printed out using the fixed code.

Repro Code:

// FIX: The Case of string_view and the Magic String -- by Giovanni Dicanio

#include <stdio.h>

#include <iostream>
#include <string>
#include <string_view>

void SomeCApi(const char* name)
{
    printf("Hello, %s!\n", name);
}

void DoSomething(std::string_view name)
{
    // BUG: SomeCApi(name.data());
    //
    // FIX:
    //
    SomeCApi(std::string{ name }.c_str());
}

int main()
{
    std::string msg = "Connie is learning C++";
    auto untilFirstSpace = msg.find(' ');

    std::string_view v{ msg.data(), untilFirstSpace };

    std::cout << "String view: " << v << '\n';

    DoSomething(v);
}

 

Level Up with Pluralsight – Learn FREE for All April

Just a heads up to let you know that Pluralsight is making all video courses FREE for the month of April!

Are you interested in getting started with the C programming language?

What about getting to know some practical features of C++14 and C++17?

Do you need a practical introduction on how to use the C++ Standard Library’s containers (like std::vector, std::list, std::map, std::unordered_map, etc.)?

Would you like an introduction to data structures and algorithms in C++?

Or would you like to learn modern C++ from scratch?

All these courses of mine and 7,000+ other courses are available for FREE for all April!

Level up your tech skills for free all month long. Click the banner below to access Pluralsight #FreeApril!

The Case of string_view and the Magic String


Someone was working on modernizing some legacy C++ code. The code base contained a function like this:

void DoSomething(const char* name)

The DoSomething function takes a read-only string expressed using a C-style string pointer: remember, this is a legacy C++ code base.

For the sake of this discussion, suppose that DoSomething contains some simple C++ code that invokes a C-interface API, like this (of course, the code would be more complex in a real code base):

void DoSomething(const char* name) 
{
    SomeCApi(name);
}

SomeCApi also expects a “const char*” that represents a read-only string parameter.

However, note that the SomeCApi cannot be modified (think of it like a system C-interface API, for example: a Windows C API like MessageBox).

For the sake of this discussion, suppose that SomeCApi just prints out its string parameter, like this:

void SomeCApi(const char* name) 
{
    printf(“Hello, %s!\n”, name);
}

In the spirit of modernizing the legacy C++ code base, the maintainer decides to change the prototype of DoSomething, stepping up from “const char*” to std::string_view:

// Was: void DoSomething(const char* name)
void DoSomething(std::string_view name)

The SomeCApi still expects a const char*. Remember that you cannot change the SomeCApi interface.

So, the maintainer needs to update the body of DoSomething accordingly, invoking string_view::data to access the underlying character array:

void DoSomething(std::string_view name) 
{
    // Was: SomeCApi(name);
    SomeCApi(name.data());
}

In fact, std::string_view::data returns a pointer to the underlying character array.

The code compiles fine. And the maintainer is very happy about this string_view modernization!

 

Then, the code is executed for testing, with a string_view name containing “Connie”. The expected output would be:

“Hello, Connie!”

But, instead, the following string is printed out:

“Hello, Connie is learning C++!”

Wow! Where does the “ is learning C++” part come from??

Is there some magic string hidden inside string_view?

As a sanity check, the maintainer simply prints out the string_view variable:

// name is a std::string_view
std::cout << “Name: “ << name;
 

And the output is as expected: “Name: Connie”.

So, it seems that cout does print the correct string_view name.

But, somehow, when the string_view is passed deep down to a legacy C API, some string “magic” happens, showing some additional characters after “Connie”.

What’s going on here??

Figuring Out the Bug

Well, the key here are two words: Null Terminator.

In fact, the C API that takes a const char* expected the string to be null-terminated.

On the other hand, std::string_view does not guarantee null-termination!

So, consider a string_view that “views” only a portion of a string, like this:

std::string str = “Connie is learning C++”;
auto untilFirstSpace = str.find(‘ ‘);
std::string_view name{str.data(), untilFirstSpace}; // “Connie”

The string_view certainly “views” the “Connie” part. But, if you consider the memory layout, after these “Connie” characters in memory there is no null terminator, which was expected by the C API. So, the C API views the whole initial string, until it finds the null terminator.

So, the whole string is printed out by the C API, not just the part observed by the string_view.

Memory layout: string_view vs. C-style null-terminated strings
Memory layout: string_view vs. C-style null-terminated strings

This is a very subtle bug, that can be hard to spot in more complex code bases.

So, remember: std::string_views are not guaranteed to be null terminated! Take that into consideration when calling C-interface APIs, that expect C-style null-terminated strings.

P.S. As a side note, std::string::c_str guarantees that the returned pointer points to a null-terminated character array.

> Follow up here.

Repro Code

// The Case of string_view and the Magic String 
// -- by Giovanni Dicanio

#include <stdio.h>

#include <iostream>
#include <string>
#include <string_view>

void SomeCApi(const char* name)
{
    printf("Hello, %s!\n", name);
}

void DoSomething(std::string_view name)
{
    SomeCApi(name.data());
}

int main()
{
    std::string msg = "Connie is learning C++";
    auto untilFirstSpace = msg.find(' ');

    std::string_view v{ msg.data(), untilFirstSpace };

    std::cout << "String view: " << v << '\n';

    DoSomething(v);
}

New Pluralsight Course on Getting Started with the C Language

Hi!

My new Pluralsight course on Getting Started with the C Language is LIVE!

In this course you’ll learn in a practical way, with a combination of slides and demo code, the basic aspects of the C programming language and tools, so that you can start being productive with the C language.

Starting from this course page, you can freely play the course overview, and read a more detailed course description and the table of content.

Some of the major topics include: understanding the role of the C compiler, and compiling from both the command line and using an IDE; learning about common basic types and basic I/O; learning the syntax for decision making in C (e.g. the if-else and switch statements) and how to write loops (e.g. for, while and do-while); the basics of working with strings; learning how to write your own functions. Pointers will be introduced, as well.

I’ll also show some subtle C beginner’s bugs, I will analyze them and discuss how to fix them.

Inspecting the content of a C string.
Inspecting the content of a C string.
Discussing the memory layout of strings in C.
Discussing the memory layout of strings in C.
Analyzing a subtle bug.
Analyzing a subtle bug.
Introducing pointers in C.

These are some feedback notes from my reviewers:

The content is presented with great clarity and is organized effectively. Great module. [Peer Review]

I really like that your demos are very concise and tightly focused on the syntax and concepts you’re explaining. There’s nothing extra to cause confusion. Well done! [Peer Review]

Your code slides are well-designed and easy to read. [Peer Review]

I REALLY like that you explained the potential problem with […]. I wish more people would heed the advice you present here. [Peer Review]

Very clean module with clear explanations and demos. Great job! [Peer Review]

Happy learning!

 

Pluralsight Black Friday 40% Off

Just wanted to give you all a heads up about current Pluralsight Black Friday 40% Off promotion on all Personal Annual and Premium subscriptions.

Click on the banner below to save now.

The Case of the Context-Menu Shell Extension That Doesn’t Get Invoked by Explorer

A developer was working on a context-menu shell extension.

He wrote all the skeleton infrastructure code, including some code to display the selected files when the shell extension gets invoked by Windows Explorer. It’s kind of the “Hello World” for context-menu shell extensions.

He happily builds his code within Visual Studio, copies the shell extension DLL to a virtual machine, registers the extension in the VM, right-clicks on a bunch of files… but nothing happens. His extension’s menu items just don’t show up in the Explorer context-menu.

What’s going wrong, he thought?

He starts thinking to all sorts of hypotheses and troubleshooting strategies.

He once again manually registers the COM DLL that implements the shell extension from the Command Prompt:

regsvr32 CoolContextMenuExtension.dll

A message box pops up, informing him that the registration has succeeded.

He tries right-clicking some files, but, once again, his extension’s menu items don’t show up.

He then checks that the extension was properly registered under the list of approved shell extensions (this was part of his shell extension infrastructure C++ code):

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Shell Extensions\Approved

He finds the GUID of the shell extension in there, as expected.

He then checks that the extension was registered under the proper subkey in HKEY_CLASSES_ROOT. Found it there, too!

He starts wondering… what may be going so wrong?

He checks the C++ infrastructure code generated by the ATL Visual Studio wizard, including his own additions and modifications. The implementations of DllRegisterServer and DllUnregisterServer seem correct.

He also checks his own C++ code in the C++ class that implements the shell extension’s COM object. He has correctly implemented IShellExtInit::Initialize, and the three methods of IContextMenu: GetCommandString, InvokeCommand, and QueryContextMenu.

He takes a look at the class inheritance list: both IShellExtInit and IContextMenu are listed among the base classes.

The IShellExtInit and IContextMenu COM interfaces are correctly listed among the base classes.
The IShellExtInit and IContextMenu COM interfaces are correctly listed among the base classes.

He feels desperate. What’s going wrong?? He wrote several shell extensions in C++ in the past. Maybe there’s some bug in the current version of Visual Studio 2019 he is using?

Why wasn’t his context-menu shell extension getting called by Explorer?

 

I took a look at that code.

At some point, I was enlightened.

I gave a look at the COM interface map in the header file of the C++ shell extension class.

There’s a bug in the shell extension C++ object’s COM interface map.
There’s a bug in the shell extension C++ object’s COM interface map.

Wow! Can you spot the error?

Something is missing in there!

In fact, in addition to deriving the C++ shell extension class from IContextMenu, you also have to add an entry for IContextMenu in the COM map!

I quickly added the missing line:

    COM_INTERFACE_ENTRY(IContextMenu)

The COM interface map, with both the IShellExtInit and IContextMenu entries.
The COM interface map, with both the IShellExtInit and IContextMenu entries.

I rebuilt the extension, registered it, and, with great pleasure and satisfaction, the new custom items in the Explorer’s context-menu showed up! And, after selecting a bunch of files to test the extension, the message box invoked by the shell extension C++ code was correctly shown.

All right! 😊

So, what was going wrong under the hood?

Basically, since the context-menu shell extension was correctly registered under the proper key in the Windows Registry, I think that Windows Explorer was actually trying to invoke the shell extension’s methods.

In particular, I think Explorer called QueryInterface on the shell extension’s COM object, to get a pointer to IContextMenu. But, since IContextMenu was missing from the COM map, the QueryInterface code implemented by the ATL framework was unable to return the interface pointer back to Explorer. As a consequence of that, Explorer didn’t recognize the extension as a valid context-menu extension (despite the extension being correctly registered in the Windows Registry), and didn’t even call the IShellExtInit::Initialize method (that was actually available, as IShellExtInit had its own entry correctly listed in the COM map from the beginning).

The bug is in the details!

So, the moral of the story is to always check the COM map in addition to the base class list in your shell extension’s C++ class header file. The COM interfaces need to both be in the base class list and have their own entries in the COM map.

And, in addition, to me this experience has suggested that it would have been great if Visual Studio had issued at least a warning for having the IContextMenu COM interface listed among the base classes, but missing from the COM map! This would be an excellent time-and-bug-saving addition, Visual Studio IDE/Visual C++/Visual Assist X teams!