Is "dog-tag" fields used in some software?

Question

I am reading the book named "Code Complete". In the book, there is an explanation of "dog-tag field".

Use dog-tag fields to check for corrupted memory. A "tag field" or "dog tag" is a field you add to a structure solely for the purpose of error checking.

Have you ever seen the actual usage of the "dog-tag" field in your software or in some software used by many users?

Answer 1

The "dog-tag" fields, or checksums, are still in use. They are primarily used in data transmission.

The memory in most computers, embedded and desktop, has improved in quality. There are fewer checks on memory and those checks are quick tests performed during power-up of a computer.

If your data is very critical and important data, you may want to use a 'dog-tag' or checksum field. This could prove useful when writing to hard drives.

Some error checking schemes store values that will help reconstruct the data if there is any corruption.

The field will need to be updated if any data member in the structure is intentionally changed. This will negatively impact the performance of your program.

Answer 2

What McConnell calls "dog-tags" is simply putting a field in a data structure that you initialize with a recognizable value. When the structure is freed, the tag field should be 'erased'.

struct foo {
    unsigned int tag;
    int bar;
    char baz[20];
    char* qux;
};

enum {
    tag_freed = 0xcfcfcfcf,
    tag_foo = 0x206f6f66,   // "foo " in little-endian
};

struct foo* foo_alloc(void)
{
    struct foo template = {tag_foo};

    struct foo* p = malloc(sizeof struct foo);
    if (p) {
        *p = template;
    }

    return p;
}


int foo_validate(struct foo* p)
{
    return p && (p->tag == tag_foo);
}

void foo_free(struct foo* p)
{
    if (p) {
        if (!foo_validate(p)) error_handler(/* ... */);

        p->tag = tag_freed;
        free(p);
    } 
}

There are several nice things about these kinds of tags:

• they're pretty inexpensive
• when dumping raw memory in a debugger you can get a clue what's in the raw memory. This can be handy for memory leaks.
• some minimal detection of memory corruption
• can help find pointers that end up pointing to no longer valid objects

The Windows kernel provides built in support for tagged memory allocations for drivers (in which case the tag is managed by the kernel pool manager and is external to the structure defined in the driver source code):

• An Introduction to Pool Tags

Answer 3

Modern C/C++ runtimes often give you the option to allocate extra space after an allocation, filled with a special sentinel value, and then check that value later to make sure it hasn't been overwritten.

Doing this manually is a lot of work for questionable benefit. I certainly wouldn't do it until I suspected that there was an actual memory overrun bug... and then only if, for some strange reason, I couldn't just do range checking in the accessor functions.

There are exceptions, relating to inter-processor communication utilities for certain unusual computer architectures, but in general I would not make such checking an explicit part of a class.