One of the great things about C, and even more so for C++, is its strong type checking mechanisms. In general a lot of bugs are caught at compile time, and experienced programmers are able to recognize and fix these types of errors quickly.

Unfortunately, there are plenty of places in any C program where type checking disappears. The GNU C compiler, gcc, goes above and beyond the call of duty to help in these areas. But sometimes that help can be a can of worms all of its own.

An Example of Type Safety MIA

A classic example of type safety gone into hiding is found with the formatted I/O functions in C: s/f/printf() and s/f/scanf(). These function families take a formatted string that defines what type of arguments they are expecting to either read or write, followed by a variable length list of arguments. The arguments passed in must match up precisely with the formatted argument string in type and quantity. The problem is that the traditional compiler, which is concerned with the language, doesn’t really know how to check that argument list.

Over the years this has lead to many spectacular bugs, when an original programmer or someone doing maintenance inserts a mismatch:

    int parse_user_name( char *name, size_t namel )
    {
        printf( "Please provide a name:" );
        sscanf( "%s", namel );
    }

In some cases, such as the simple one character typo shown above, you now have a system that can be easily exploited using off-the-shelf tools for code injection. Very bad stuff.

GNU to the Rescue

Traditional C compilers have let this kind of bad code go by without a second glance. Back in the day, the responsibility for this deeper type of checking rested with a useful program called lint. But as the C standard tightened up over the years, fewer people saw a need for lint, and routine checks for these types of problems often disappeared from the build process.

Somewhere along the way, (I first started noticing in the 4.x era) the GNU compiler people began inserting some proactive code to flag errors that once where the province of lint. Just as an example, this short piece of broken code compiles with no warnings when using default settings for gcc 3.4, 4.1, and the Sun C compiler v5.7:

#include 

int main()
{
    printf( "%s\n", 1.2 );
    return 0;
}

But gcc 4.5.2 correctly sees a big problem, and issues a warning:

gcc.c: In function 'main':
gcc.c:5:5: warning: format '%s' expects type 'char *', but argument 2 has type 'double'

Since it is valid C code, the compilation proceeds, but at this point it is caveat emptor.

How Far Do You Go?

I ran into trouble with this GCC feature when working up an in-class demonstration of redirected I/O on a Linux system. I hypothesized that the early, paleolithic code to redirect standard output for a child process might have looked something like this:

#include <unistd.h>
#include <stdio.h>
#include <fcntl.h>

int main (int argc, char *argv[]) {
  if ( argc <= 2 ) {
    printf( "Usage: test command file\n"
            "The command will be executed"
            "with stdout going to file\n" );
    return -1;
  }
  if (fork() == 0) {
    close(STDOUT_FILENO);
    open(argv[2], O_WRONLY | O_CREAT, 0744);
    printf( "About to execute %s\n", argv[1] );
    fflush( stdout );
    execl(argv[1], 0);
    printf("I will never be called\n");
  }
  sleep ( 2 );
  printf("Execution continues in"
         " the parent process\n");
  return 0;
}

This code does just what we want when executed with a command like: ./a.out /bin/ls output.txt. The ls command is executed, and its standard output is redirected to the file output.txt.

However, several of my students reported that they were getting mysterious compiler errors on this same code. Sure enough, when running under gcc 4.5, we get this:

exec.c: In function 'main':
exec.c:17:6: warning: not enough variable arguments to fit a sentinel

For beginning C programmers, this kind of error can be a real time sink. The error message uses terminology that is compiler-specific, it doesn’t provide a detailed description of exactly what it doesn’t like, and it doesn’t recommend a solution. Google searches for this specific error do lead to a solution, but they will ask a bit of work from the novice.

The first lesson my students picked up is that you need at least one more argument to this function call. While it is true that people normally call execl() with arg0 set to the filename, this is by no means required. And in fact, most programs will work just fine with an argument count of 0. There is really no good way to know which programs require arg0, or further args, without reading the documentation. In any case, gcc is pushing things a bit by insisting on this.

So changing the line of code that calls exec to:

    execl(argv[1], argv[1], 0);

should fix the problem, right?

Wrong. This reconfiguration gets a slightly different error:

exec.c: In function 'main':
exec.c:17:6: warning: missing sentinel in function call

As it turns out, gcc really wants you to cast the literal value 0 to a pointer:

    execl(argv[1], argv[1], (char*) 0);

Which finally makes the error go away.

This is a bit annoying, because both my C and C++ standards clearly say that a constant integral value of 0 can convert to any pointer type without any fuss. So why should I have cast it to a char * before passing it to execl?

Well, it won’t make a difference on any of the computers I use, but if you are on a computer where an integral type is passed on the stack with fewer bytes than a pointer, you may run into trouble. execl() is not smart enough to know that the 0 you are passing is actually terminating the argument list – it may just be an integer – so an integer is what is pushed on the stack.

Confusion

So yes, gcc’s lint-like characteristics made my lecture a bit more complicated. I had to explain a few things that I had hoped to gloss over. But on the other hand, the casting of 0 to a pointer type is actually a pretty important thing, and I’m glad gcc reminded me of it.

Requiring a value of arg0 when using execl() seems to me less like something that requires reminding, but nonetheless, it certainly won’t do any harm to follow this advice.

C++ does a good job of inserting type safety into places where it hasn’t been seen before. For example, you can do all your I/O in C++ with some assurance that you are not making those traditional mistakes seen with scanf or printf. However, the C++ standard library is not likely to tackle the APIs for Linux or Unix system calls, meaning we should be appreciative of the help we get from gcc.

So to whoever wrote the code that checks for sentinels in gcc, I thank you.

In my last post I showed a particularly easy way to to set up an SMTP server so postfix could send mail from your Linux system. In this post I’m going to add a few tips that might help you get through some rough spots in the whole process.

Results From the Field

After writing a HOWTO page, there is no better test of its quality than to try it out with a group of students performing the task for the first time. That’s just what I did with my SMTP configuration post – I created a homework problem that asked my students to set up outbound email on their personal Linux systems.

Their resulting glitches highlighted a few rough spots in the process, most of which can be handled pretty easily.

Debian Package Configuration

When you install postfix on Ubuntu, you will normally get kicked into a simple package configuration dialog after the package has been downloaded and installed. This final step performs some very basic setup on postfix, getting into a roughly functional state.

If this configuration doesn’t run, postfix seems to be configured to only handle local mail – messages from one user to another. In some cases this may be just what you want, but normally it is not all that useful.

For unknown reasons, this configuration pass doesn’t always kick off properly. I’ve seen it fail to run, and some students have as well. Fortunately, you can execute the same process by hand from the command line:

sudo dpkg-reconfigure postfix

Running through this, I take the default settings for everything except Root and postmaster mail recipient, which I change to student, the name of my account on this system. After this is complete, following the instructions from my previous post will give you a proper Internet email setup.

Using Mailjet instead of SendGrid

After some glitches getting accounts on SendGrid, I had a couple of students decide to use Mailjet as an STMP provider. Registering with Mailjet is easier, as it an automated process. However, using Mailjet as your SMTP provider comes with a couple of interesting twists.

First, instead of using your Mailjet account credentials to authenticate with their SMTP server, Mailjet gives you a set of strong credentials specifically for SMTP authentication. You have to copy these from your Account Info page. No problem there, as long as you RTFM.

Slight more problematic is that Mailjet insists that the return address you use in your outbound emails must be an authenticated address. In other words, you have to be able to receive an email sent to that address and click on an authentication link.

When using postfix’s default settings, email sent by my students was going out with a return address of student@ubuntu, and there is obviously no way to authenticate that address. So we have to rewrite that address to something usable.

After taking that additional requirement into account, my changes to /etc/postfix/main.cf for Mailjet are shown below. The file had a default relayhost entry, which is replaced, and the remaining lines are all new. The username and password have to be replaced with the ones from your Mailjet account page:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = static:username:password
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
relayhost = [in.mailjet.com]:587
smtp_generic_maps=texthash:/etc/postfix/generic

The last line I added to the configuration tells postfix to look in a file called /etc/postfix/generic for a list of substitutions to make to email addresses found in headers being processed. I create a single line in this file:

student@ubuntu yourmail@yourprovider.tld

This entry in the map file changes the local student account to an authenticated email address. After making this change, emails sent from the student account will have their headers rewritten to give a sender identity of your personal email address, which means Mailjet will happily forward your messages to their final destination.

Once that’s done, I restart postfix and send a test message:

sudo /etc/init.d/postfix restart
echo hello | mailx -s "test mail" myemailaddress

The headers on my received email show that things worked more or less as expected:

One nice thing about using the generic substitution file is that now you can accommodate different sender email addresses for every account on your system. Since you have to enter account info by hand, this doesn’t scale to a large enterprise, but it works just fine for your personal system.

There’s no doubt that the complexities of managing mail on a Linux system is still a bit daunting, but at least the process of simply getting outbound mail working is manageable. Give it a shot!

I received a sad email from Andy Johnson of Greenleaf Software yesterday, giving me the news that Greenleaf’s founder Don Killen died in his sleep Monday, August 21, 2006.

Don was a pioneer in the world of desktop C and C++ programming, since he sat down in 1982 and hammered out his flagship product, Greenleaf Functions. Back in the days when MS-DOS programmers still had to use the Lattice C compiler, Don saw that there was potential big market for a library that provide glue between the BIOS, the DOS API, and C programmers. Armed with references and a copy of MASM, he created the product, placed a few ads, and found himself with enough orders to go into the business full time. (Mind you, this was back in the early 80s, and Don was managing to get over $200 a pop for this library.) You can follow Don’s version of that history here.

I went to work for Greenleaf in 1989 after burning most of my bridges with telephony startup SRX (later absorbed by Teltronics.) It was a big change for me – Greenleaf was a small family business and I had to try to learn how to operate in that kind of environment. During all my years with Greenleaf, I could never forget that it was Don’s world, and we were lucky to get to play in it.

Greenleaf had quite a few good years, but as the 90s waxed the product mix wasn’t attracting the kind of sales that it needed to keep the place going, and Don’s health was always an issue. Despite a fortunate kidney transplant, as he got older, I don’t think he had the energy and vigor he needed to reinvent the company for the new millenium. Seeing the writing on the wall, the development team branched off to form a contract programming company called Addisoft Consulting. Tammie Williams, Patrick Little and Ruby Hjelte are still there, and worked with Don and Greenleaf from time to time.

Working with Don was a great experience, and I can honestly say that I learned more about the software business from both him and Tammie than I could have managed anywhere else. It was a rare opportunity for an inexperienced programmer, and I really feel luck to have had the opportunity, and to have gotten to know Don.

May he rest in peace.

Dr. Dobb's Journal June, 2000 by Mark Nelson and Ping Ni

Windows users are all familiar with the concept of DLL hell. This occurs when applications try to work with mismatched versions of DLLs, resulting in bugs, poor performance, and even system crashes. Although all operating systems are vulnerable to versioning troubles, Windows seems to be particularly prone to problems in this area.

Under certain circumstances, DLL hell can become magnified to an excruciating level. We found ourselves in position over the last several months while working on a large development project. This project involves geographically scattered teams of programmers, distributed object technology, and dozens of DLLs and executables. With interfaces and capabilities changing on a daily basis, we found that a good system of version management was crucial to our continued progress. When the system breaks down, mass confusion can idle dozens of highly paid programmers and Q/A personnel. This is not a good thing.

Where we need it

To get this problem under control, we first identified four critical places where we need to know the version of an executable or DLL.

1: When looking directly at a file

Working with developers when a project is changing rapidly can be very frustrating for Q/A people. It seems that no matter what sort of problem they report, the immediate response from development goes something like “You need to get the latest version, that bug has been fixed.”

Because of this sort of response, it is vital that end users be able to easily determine what version of a DLL or executable is installed on their system. To make this as easy as possible, Microsoft created a standardized method for setting product versions under Windows. One of the standard resource types that can be bound to a project is a Version resource. Our project is built using Visual C++, which stores the version resource in an RC file. Figure 1 shows a typical view of this version information from the IDE.

Figure 1
Version information in a Visual Studio project

Note that the resource shown in Figure 1 appears to have duplicates of the version information. The Key values named FILEVERSION and PRODUCTVERSION in the upper half of the display are in the fixed-info section of the resource. These two values are stored as DWORDs in the EXE or DLL file, and as such are useful for using in numerical tests of version properties. The values labeled FileVersion and ProductVersion are string parameters, and are useful for displaying to end users or printing in trace files. Keeping numbers in two places certainly makes us more vulnerable to mistakes, but sometimes we have to make compromises to do things the Microsoft way!

Once the version information is bound into the executable or DLL, an end user can view it by simply asking for the properties of the file from an Explorer view. Figure 2 shows the version information that Windows displays from this view. (Note that the O/S shows the string values, not the fixed-info numeric values.)

Figure 2
The Win32 file properties dialog

2: When reading trace files

One very common technique used to capture debugging information is the use of a trace or log file. This is usually a simple ASCII text file that can be easily viewed or printed out. Q/A testers know that if they can attach a trace file to a bug report the odds of a fix improve greatly. Unfortunately, developers will always want to know what version of the program was used to create the trace file.

A proactive way to deal with this question is to always print the component version number as one of the first lines in a trace file. That can be done with a line as simple as this:

3: Checking versions at run time

A standard part of any Windows program is the generic About Box. Good programmers always take care to include version information in the About Box. Figure 3 shows a sample of this dialog from a typical Windows application.

Figure 3
The About Box from Microsoft Outlook Express

The About Box is just a simple Windows Dialog, which is usually defined in the RC file along with other resource information. The simplest (and probably most common) way to put the version information in the dialog is to create a static text resource that contains the ASCII text verbatim.

4: Checking out modules from source code control

Source code control is a key component of modern team-based development. Every source code control system in use today allows programming teams to label a package of files with a version number. That package can then be retrieved by name at any time in the future, which gives developers an easy way to follow the life history of bugs. We frequently find that Q/A is testing a product release that is a few versions behind what development is presently testing.

We use Visual Source Safe for our source code control system. Most of our development staff uses the GUI based front end for this program. When we want to identify a particular version of our package, we right click on a project, and then select the Label menu item. This brings up a dialog box as shown in Figure 4. Typing in the version number causes Visual Source Safe to create a checkpoint for every file in that project. At any time in the future we can ask VSS for copies of all the files for that particular version. (This can include executable and DLL versions as well.)

Figure 4
Labeling a project in Visual Source Safe

What’s wrong with this picture?

At this point it might seem that we’ve got our version control problem pretty well under control. But experienced programmers should see right away that we’ve got a real problem. We’ve got one piece of data, the version number, and it has to be stored in four different places. This situation should set off alarms any time you see it, because we’ve set up a system that only works if we have perfect adherence to a multi-step procedure. Updating version numbers means editing an RC file in at least two places, locating and editing trace file function calls, and correctly determining the projects to label in the source code control system.

A typical situation we run into at work might have a team of ten people working on the release of fifteen or twenty components. To make sure that we update all version information correctly might involve as many as fifty separate procedures. What are the chances that someone might forget to update the version number in a single About Box, or incorrectly label the VSS project in question? A single mistake such as this can cause immense confusion the next time a bug is reported for a incorrectly identified component.

While it would be possible to create a written procedure list and require people to verify each and every step, it’s infinitely better to set up a system that allows for one-step version setting system. By updating all version information in one step, we are no longer vulnerable to human frailty. If the process is set up properly one time, it should work correctly every time it is used in the future.

The Perl Solution

Physicists have been battling for years to unify the four fundamental forces of nature: gravity, electromagnetism, the weak force, and the strong force. While it may have been hubris on our part, we were determined to find a unified way to set the versions in the four different areas of our development process.

The key to the solution was finding a programmatic way to update the version numbers used everywhere in the program. The only thing we needed to do in order to make this happen was to modify the version resource in each component’s RC file. This meant doing a bit of simple parsing and text modification. And without a doubt, the tool most suitable to this task has to be Perl.

Using Perl, it was a quick matter to write a script that we now use to increment either the major or minor version of an entire batch of components. The resulting script, IncVersion.pl, is shown in Listing 1.

IncVersion.pl is invoked with an initial argument of major or minor, followed by a list of projects. It then works its way through each of the projects, modifying the RC file for each project. There are two lines in each RC file that need to be modified. The first looks something like this:

And the second looks like this:

The Perl script locates this line in each RC file, and updates the version number in one of two ways. If the initial argument is minor, the last digit in the version is incremented. For example, the version in the lines shown above will change from 5.1 to 5.2. If the initial argument is major, the first digit in the version is incremented. The version above would change from 5.1 to 6.0. (Note that this simple example uses version numbers with just two components.) The FILEVERSION string in the two examples would change to either 5,0,2,0 or 6,0,0,0.

Some programming details

The Perl script IncVersion.pl provides an automated way to change the version resource for a given DLL or EXE. By executing it with the correct list of projects, it's possible to automatically update all the components of a big project in an automated way. This is clearly going to cut down on procedural and typing mistakes. But it is still a long way from a unified version system. This only affects the first place where we need version information, which is in the Windows property view. The remaining three cases don't get any help from this at all.

As it turns out, two of the remaining cases are fixed with just a bit of code. In the strategy we were using previously, the version numbers sent to the trace file and shown in the About Box were both hard-coded. A better strategy is to extract the version information from the RC file. Listing 2 shows a C++ routine that can be used to get the version number from the RC file for a given module. We provide routines to read the version information from either the fixed-info or string version resources. (In practice you can arbitrarily choose one or the other.) Now my logging output should look something like this:

Likewise, the About Box code can be generated dynamically as well. If your About Box is a standard Windows Dialog, you only have to override the WM_INITDIALOG message and insert the appropriate text into a static text control. In an MFC app, the code might look something like this:

BAT file considered helpful

By using these minor modifications, we now have automatic version number control in three of the four designated places. Unfortunately, the fourth target of our version control system is a little more difficult to deal with. Remember that each new version of our project needs to have a label associated with it under our version control system. It would be nice if Visual Source Safe could just read the contents of the version resource in each project's RC file, but at this time it doesn't know how to do that. Accordingly, we have to manually label each new version of our project after it has been checked in.

Although we usually use Visual Source Safe's GUI interface, it can also be invoked from the command line. We make use of this in our versioning system by having IncVersion.pl generate a BAT file that will apply the appropriate label to the currently selected project in Visual Source Safe. A typical LABEL.BAT file will look like this:

The Perl script can be modified to generate the project label you want, the important thing is that the version number in the label is identical to that placed in the RC files.

Given the existence of LABEL.BAT, tying all the pieces of the puzzle together is done via one master BAT file. Ours is called UPDATE.BAT, and it looks something like this:

The BAT files called to check out the projects, build the components, then check them back in are all very specific to our projects, and will need to be tailored to each projects needs. CHECKIN.BAT and CHECKOUT.BAT just make calls to the command line interface of Visual Source Safe. MAKEALL.BAT invokes the command line NMAKE tool supplied with Visual Source Safe.

Conclusion

Managing version information in a large project doesn't have a nice tidy management solution, at least not with our Win32 development tools. However, by making a few modifications to our source code, and resorting to some old-fashioned command line tools, we have developed a system that does a great job of protecting us from minor version snafus. It does this by doing all version updates in one fell swoop, which makes sure that the process occurs across all components of the system at once. It isn't perfect, and may not even be ideal, but it's working for us.

Listings

Listing 1
IncVersion.pl:

Listing 2
Getting VersionInfo in C++: