Down the Rabbit Hole

AuthorizationExecuteWithPrivileges() will fail with errAuthorizationInternal if there is no TEMPDIR

2010-03-04T01:18:00.001+03:00

On Mac OS X function AuthorizationExecuteWithPrivileges() will fail with error errAuthorizationInternal (-60008, "something else went wrong.") if environment variable TMPDIR points on invalid (not existent) path. The reason of such weired behavior is call to tmpfile() inside the AuthorizationExecuteWithPrivileges() function. The moral is - use more explanatory error codes :)

Some more info on that issue can be found in Apple Mailing Lists.

Classes generated from XAML (in WPF) are public by default

2010-02-14T00:36:00.001+03:00

In Windows Presentation Foundation, classes generated from XAML markup have public visibility by default. Why not internal (like interfaces)? I don't want my application GUI private classes to be visible from the outside of its assembly. More over, it is not possible to alter that default in language-neutral way. One need to use x:ClassModifier attribute in XAML root element to change class visibility specifying language-dependent value (internal for C#, Friend for VB).

Links on the topic:
- Nice post about that problem
- MSDN article on x:ClassModifier
- Microsoft Connect ticket on that problem

The right way to check whether the C string is empty

2009-11-25T00:09:00.003+03:00

It is:

char *s;
// .. do something with s ...
if (!*s) printf("empty!\n");

if (0 == *s) printf("empty!\n");

I prefer the second one, because find it easier to read, but it doesn't matter really.

The most popular bad ways to do this:

```
if (0 == strlen(s)) printf("empty\n");
```

if (0 == strcmp(s, "")) printf("OMG, empty!\n");

And it is not a joke, today I saw 2 independent reviews with such kind of stuff.

p.s. There is a popular joke about how foreign developers check bool value to be a true:
if (4 == strlen(bool2str(value))) printf("its true!\n");

Structure and class methods have external linkage

2009-11-08T11:49:00.149+03:00

Lets look on small example:
File f01.cpp:

#include <stdio.h>
struct TEST
{
    TEST() { printf("TEST from f01: created\n"); }
    unsigned m;
};
void f01()
{
    TEST t;
    printf("TEST from f01: sz=%u\n", (unsigned)sizeof(t));
}

File f02.cpp:

#include <stdio.h>
struct TEST
{
    TEST() { printf("TEST from f02: created\n"); }
    unsigned m1;
    unsigned m2;
};
void f02()
{
    TEST t;
    printf("TEST from f02: sz=%u\n", (unsigned)sizeof(t));
}

File main.cpp:

#include <stdio.h>
void f01(); // prototype
void f02(); // prototype
int main(int argc, char *argv[])
{
    (void)argc; (void)argv;
    f01();
    f02();
    return 0;
}

Program output:

TEST from f01: created
TEST from f01: sz=4
TEST from f01: created
TEST from f02: sz=8

As you can see structure TEST from f01.cpp will be constructed in both f01() and f02() functions. In function f02() it will be allocated 8 bytes for TEST structure (since it has two unsigned members in f02.cpp), nevertheless constructor of TEST from f01.cpp will be called. I think it is clear enough that calling incorrect constructor is a bad thing, and it is better to avoid it.

The reason of such behavior, is that structure and class methods have external linkage. It is done to make it possible to use structure or class from another translation unit (*.cpp file). Therefor compiler will generate two TEST::TEST() external symbols, one for each TEST structure. Linker, when linking all three files together, will not be able to understand what TEST::TEST() to use in every particular case, so it will pick just the first one. I don't know why there is no linkage warning (or even error) for such situation (in both gcc and MSVC).

The solution is to put declaration of TEST structure in anonymous namespace:
File f01.cpp:

#include <stdio.h>
namespace {
    struct TEST
    {
        TEST() { printf("TEST from f01: created\n"); }
        unsigned m;
    };
}
void f01()
{
    TEST t;
    printf("TEST from f01: sz=%u\n", (unsigned)sizeof(t));
}

File f02.cpp:

#include <stdio.h>
namespace {
    struct TEST
    {
        TEST() { printf("TEST from f02: created\n"); }
        unsigned m1;
        unsigned m2;
    };
}
void f02()
{
    TEST t;
    printf("TEST from f02: sz=%u\n", (unsigned)sizeof(t));
}

Program output:

TEST from f01: created
TEST from f01: sz=4
TEST from f02: created
TEST from f02: sz=8

By putting declarations in anonymous namespace we force them to have internal linkage, and therefor not to confuse linker with their symbols.

Bonus example:
File f01.cpp:

#include <stdio.h>
struct TEST { unsigned m; };
void f01() { TEST t; }

File f02.cpp:

#include <string>
#include <stdio.h>
struct TEST { std::string s; };
void f02()
{
    TEST t;
    printf("t.s=\"%s\"\n", t.s.c_str());
}

Example will crash since constructor of TEST structure from f01.cpp doesn't call constructor of TEST::s member from f02.cpp.

Top level window receives WM_GETMINMAXINFO before WM_NCCREATE

2009-11-07T22:38:00.001+03:00

Keep in mind, that on Windows top level window receives WM_GETMINMAXINFO message prior to WM_NCCREATE. Such behavior can be fatal for application that executes window initialization code in WM_NCCREATE message handler, since when receiving WM_GETMINMAXINFO window is not initialized yet.
Oh, that cruel, stupid world...

Another good reason not to run program by its name in Windows

2009-10-22T04:27:00.008+04:00

When searching for executable by its name Windows always looks in:

Current working directory
Windows system directory (use GetSystemDirectory() to obtain it)
Windows directory (use GetWindowsDirectory() to obtain it)
Directories listed in PATH environment variable

This list (I will refer to it as search directories) can be expanded with more directories when performing specific tasks.
If name does not contains file extension (for example notepad or attrib), Windows will use glob "name.*" to find file with extension that is listed in PATHEXT environment variable.

It's okay if you need just to run notepad or mspaint from command line. But what if you need to execute some program many times? Well, running it by its name is definitely not your choice. I'll try to explain why.

First of all, one or more search directories can contain very many files (30000 files for example). Second, one or more search directories can be with slow access time (located on network share for example). If both is true, Windows will spend a lot of time just to locate executable to run. And the entire search will be performed again and again every time you ask Windows to execute something by its name.

Here is a simple example. Lets write small dotestiter.bat file and put it into C:\Windows\System32 directory\ (which is in search directories):

@dir /B %1

It can be executed by name (dotestiter) or by its full path (C:\Windows\System32\dotestiter.bat).
We will call it from dotest_name.bat file:

@for /R %%e in (*) do dotestiter "%%e"

And from dotest_full.bat file:

@for /R %%e in (*) do C:\WINDOWS\system32\dotestiter.bat "%%e"

Both files will call dotestiter.bat for every file in current working directory (current working directory is also in the search directories).
Results for network share with 250 files (I mounted it on Z: with net use to be able access it from command line):

dotest_name.bat - 34.6 secs
dotest_full.bat - 24.3 secs

As you can see, it is much faster to use full executable path instead of its name. For 3000 files it will be required 2 minutes of extra time just to locate the executable to run!

p.s. It is hard to reproduce the same scenario on *nix since shell does not search current working directory for program name.

Dangerous logging

2009-10-21T15:35:00.001+04:00

Today I will try to scare you:)
The most common realization of logging is something like that (simplified):

#include <stdio.h>

#ifdef _MSC_VER // workaround for MS VC
#define snprintf(b, bsz, f, ...)                \
        _snprintf_s(b, bsz, _TRUNCATE, f, __VA_ARGS__)
#endif
#define LOG_LEVEL 2
#define LOG(lvl, ...) do {                       \
    if (LOG_LEVEL < lvl) break;                  \
    char b[1024];                                \
    snprintf(b, sizeof(b) - 1, __VA_ARGS__);     \
    b[sizeof(b) - 1] = 0;                        \
    printf("%i! %s\n", (int)(lvl), b);           \
} while(0 == __LINE__)

It can be used in following way:

unsigned fp;
char *fname;
// ...
if (seekFailed)
{
    LOG(1, "Failed to seek to offset %u in file \"%s\"", fp, fname);
}

Looks safe at first glance, probably you can find something similar in your project. But lets look deeper. One of the drawbacks of logging is that it does not perform any useful work and that it is always on the most rare execution path (because usually you want to log only errors or other uncommon events). Therefore, log messages are often not tested and forgotten (in some sense it is like code comments - nobody likes irrelevant comments, but it is not a problem to find one). As a result, you can find:

LOG(1, "Failed to open file \"%s\", error %i", fname);

In that example, there is no error code passed (for %i). Bad, but relatively harmless. Just some junk value from stack or register will be logged as error code. Or something worse:

LOG(2, "Failed to rename \"%s\" to \"%s\"", oldName);

This example is very similar to previous one, except that junk from stack (or register, depending on calling convention used) will be used as pointer value (for second %s). In most cases that will lead application to crash with access violation at address. We can get more interesting example by adding large files support in the first example (with seekFailed). Variable fp probably will be declared as:

long long fp;

Oops, I will forget to replace %u in:

LOG(1, "Failed to seek to offset %u in file \"%s\"", fp, fname);

with something more appropriate (%llu). To understand why it is better not to do so, lets look on how parameters are passed to function with variable arguments list. Depending on calling convention used, parameters are placed one after another into registers and stack. Not to count particular features of each calling convention, we'll consider that all parameters are placed in abstract cells of the same size arranged side by side. So, when compiler generates function call code for function with variable arguments list it doesn't know how passed parameters will be used. All it knows is type (and therefore size) of each parameter. It has nothing to do but just place all passed parameters one by another in those cells, side by side. Every parameter will get its own cell (or cells if parameter is too large to fit in one cell). Each cell will get only one parameter (or its part), it is not possible for cell to contain two or more parameters or several parts of different parameters. Called function has access to those cells. But curiosity of situation is that called function doesn't know anything about passed parameters (even total number of parameters is mystery for it). It just gets array of raw cells (without knowing total count of cells). There for, function with variable arguments list requires some extra information to be able to handle passed parameters. Most popular example of such information is format string in functions of printf family, which contains rich information about passed parameters (type, total count and order is most important now). So, if that information about passed parameters is wrong, function will not be able to interpret content of cells properly (and therefor, entire program will not work properly). String "Failed to seek to offset %u in file \"%s\"" tells, that function will get two parameters - first of type int and second of type char *. In IA-32 (i386) both of parameters require one 32-bit cell. What will be wrong if instead of first int we'll pass long long? Size of long long in IA-32 is 64 bits. One cell will not enough for such large parameter, it will be placed in two adjacent cells, and second parameter (char *) will be placed in third cell. When function will interpret cells content it will use first cell (with first 32-bit part of fp variable) as first argument and second cell (with second 32-bit part of fp variable) as second argument (that is of type char *). The consequences of such mistake depends on value of fp:

if UINT_MAX >= fp, the second part of fp variable will be zero (it is enough 32 bits to represent numbers from 0 to UINT_MAX) and string "(null)" will be logged instead of file name
if UINT_MAX < fp, then second part of fp variable will be non-zero (probably it will not be a correct pointer on the allocated memory) and application will crash with access violation at address

Under AMD64 (x86-64) size of cell is 64 bits. Therefor every parameter will get exactly one cell (first cell for first parameter and second cell for second parameter), as it was supposed. But only 32-bit part of fp will be logged, since function still thinks that first cell contains int.

Yeh, such a horror story.

Whether this windows binary is 32- or 64-bit?

2009-10-05T14:17:00.004+04:00

The fastest way to answer on this question without using special software tools is:

Open windows binary file in any text/hex editor (notepad is enough)
Find first occurrence of "PE" string (it will be probably placed at offset 0xD0, 0xF0 or something like that after phrase "This program cannot be run in DOS mode")
Skip 2 non-printable symbols (both '\0')
Look on the symbol you are at:
- 'L' - i386 binary (x86)
- 'd' - amd64 binary (x64/x86-64)
- '\0' (zero) - ia64 binary

p.s. You can use that method for any PE binary (like .exe, .dll and others)

Games: static stuff

2009-10-03T01:45:00.016+04:00

Even the most simple thing can confuse sometimes. Usually this happens because of lack of particular experience. How to obtain such experience? Well, of course to play!

I hope it will be not the last post in that blog. Under the heading "Games" I am going to talk about things that you have always wanted to try, but because of laziness or high employment always were afraid to do it. So, let's play!

Today I want to play with static data in C++.

The theoretical conception of static data, and how it should be used can be obtained by reading the first N links on request static keyword [C++]. So, lets move to practice right now.

In my experiments I will use simple class, that will print string in its constructor and destructor. Printed string is passed as argument for constructor:

#include <stdio.h>
class CThing
{
    CThing();
    const char *const m_name;
public:
    CThing(const char *const name): m_name(name)
    { printf("CThing::CThing(\"%s\")\n", name); }
    ~CThing()
    { printf("CThing::~CThing(\"%s\")\n", m_name); }
    void echo() const { printf("echo from \"%s\"\n", m_name);
}

For the beginning, lets figure out when constructor and destructor of a static variables are called:

void someProc1()
{
    static CThing thing("thing in someProc1");
}
CThing thing1("thing1");
int main(int argc, char *argv[])
{
    (void)argc; (void)argv;
    printf("---- main() ----\n");
    someProc1();
    someProc1();
    printf("---- return ----\n");
    return 0;
}

After executing the program:

CThing::CThing("thing1")
---- main() ----
CThing::CThing("thing in someProc1")
---- return ----
CThing::~CThing("thing in someProc1")
CThing::~CThing("thing1")

As you can see, "thing in someProc1" actually created at the time of the first call to someProc1(). Destructors as it should be, are called in reverse order of constructor calls. Some people do not fully understand how static variables work, and therefore give the compiler different magical abilities. In fact, there is no magic of course. Static variable definition:

void someProc1()
{
    static CThing thing("thing");
}

compiler will translate into something like this:

bool g_thingInitialized = false;
CThing *g_thingPtr;
void g_thingDelete() { delete g_thingPtr; }
void someProc1()
{
    if (!g_thingInitialized)
    {
        g_thingInitialized = true;
        g_thingPtr = new CThing("thing");
        atexit(g_thingDelete);
    }
}

Like that easy. And because of such a simple realization of static variables, there are two issues (which are described in detail in C++ scoped static initialization is not thread-safe, on purpose!):

Contrary to popular opinion, the fact that the static variable is initialized will be checked each time function is called.
It is not thread-safe to use static variables. The compiler does not know anything about threads and does not provide any synchronization when initializing static variables. Thus, multiple instances of the class CThing can be created (plus a whole bunch of troubles, which you can get, hoping that all synchronization work will be done by compiler).

Now lets look at static class members:

class CBigThing
{
    static CThing m_thing;
    const char *const m_name;
public:
    CBigThing(const char *const name): m_name(name)
    { printf("CBigThing::CBigThing(\"%s\")\n", name); }
    ~CBigThing()
    { printf("CBigThing::~CBigThing(\"%s\")\n", m_name); }
};

class CAnyThing
{
    static CThing m_thing;
    const char *const m_name;
public:
    CAnyThing(const char *const name): m_name(name)
    { printf("CAnyThing::CAnyThing(\"%s\")\n", name); }
    ~CAnyThing()
    { printf("CAnyThing::~CAnyThing(\"%s\")\n", m_name); }
};

CThing CAnyThing::m_thing("m_thing from CAnyThing");
CThing thing1("thing1");
CThing CBigThing::m_thing("m_thing from CBigThing");

int main(int argc, char *argv[])
{
    (void)argc; (void)argv;
    printf("---- main() ----\n");
    CBigThing bigThing("bigThing");
    printf("---- return ----\n");
    return 0;
}

Program will print:

CThing::CThing("m_thing from CAnyThing")
CThing::CThing("thing1")
CThing::CThing("m_thing from CBigThing")
---- main() ----
CBigThing::CBigThing("bigThing")
---- return ----
CBigThing::~CBigThing("bigThing")
CThing::~CThing("m_thing from CBigThing")
CThing::~CThing("thing1")
CThing::~CThing("m_thing from CAnyThing")

As you can see, static class members are not created with the first instance of a class (as one would assume). They are created with other global variables in the order of their definition (and destroyed in the reverse order).

It is worth noting that the order of initialization of global variables exactly known only for variables defined in the scope of one file (module). The order of initialization of global variables in different files is not defined and depends on factors, which you probably do not want to rely on. Here is a good example of what can happen if you carelessly use global variables within different files:

// it CAN be in file actions.cpp:
extern CThing thingA;
extern CThing thingB;

bool doThings()
{
    thingA.echo();
    thingB.echo();
    return true;
}

bool doneThings = doThings();

// it CAN be in file things.cpp:
CThing thingA("thingA");
CThing thingB("thingB");

// it CAN be in file main.cpp:
int main(int argc, char *argv[])
{
    (void)argc; (void)argv;
    printf("---- main() ----\n");
    printf("---- return ----\n");
    return 0;
}

Output will be:

echo from "(null)"
echo from "(null)"
CThing::CThing("thingA")
CThing::CThing("thingB")
---- main() ----
---- return ----
CThing::~CThing("thingB")
CThing::~CThing("thingA")

Objects thingA and thingB where used uninitialized. When the code is located in a single file, the reason of such behavior is obvious - doneThings is defined before thingA and thingB. However, if you split the code on files actions.cpp, things.cpp and main.cpp (as indicated in the comments), then the situation becomes more interesting. The program can begin to work as required and print:

CThing::CThing("thingA")
CThing::CThing("thingB")
echo from "thingA"
echo from "thingB"
---- main() ----
---- return ----
CThing::~CThing("thingB")
CThing::~CThing("thingA")

But maybe not. Depends on the implementation of the compiler used (its version, the name of source files, the order in which files specified in the compiler command line, ...). I guess no one wants to have a program that can stop working after adding a new file or renaming the existing one.

Ok, I thing it's enough for beginning :)

Ping Post

2009-10-01T19:31:00.001+04:00

Meaningless post just to see that all that stuff called blogger.com works.
I don't have any super original idea for the first post, so let it be just a "ping" post.