Thread: typedef

Is there a rule of thumb for creating typedef's or is there a link that has best practices for typedef'ing in C programs?

Originally Posted by Salem

Seriously, it gets messy in a hurry.

I have to agree with you on this point.

I think your suggestions are a good starting point.

Typedefs have managed to become controversial, for who-knows-what-real-reason. The Linux coding standard decries their use. They prefer that all "struct Foo" be spelled out completely. (Not sure how they feel about non-struct typedefs, though.)

For myself, I believe that typedefs are useful and almost always appropriate, provided they are typedefs related to your problem space. As @Salem points out, pointer types are a good place to start because they can also serve to create a single-word name from a multi-part name. (This makes it possible to use macro token-pasting to good effect later on.)

Originally Posted by Salem

I'm only suggesting typedefs for function pointer types.

Regular pointers to data types should not be typedef'd.

Example.
Suppose you have
typedef int *iptr;

What if you want a const pointer.
No problem, you just do
const iptr var; // aka const int *iptr;

All well and good, but what if you want the pointer itself to be const?
You can't do that with the typedef.
So you have to retreat to long-hand anyway
int * const iptr;

I'm no expert on typedef, but this code:

Code:

typedef int *iptr;
typedef const int *ciptr;

const int foo = 42;
const iptr p1 = &foo;
ciptr p2 = &foo;

will give this warning:

Code:

180912.c:5:17: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
    5 | const iptr p1 = &foo;
      |                 ^

which suggests that p1 itself is const and points to a non-const int. On the other hand, p2 is a non-const pointer to const int.

Originally Posted by Salem

Regular pointers to data types should not be typedef'd.

Example.
Suppose you have
typedef int *iptr;

What if you want a const pointer.

You mean, "What if you want a different type?" :-) That would be a different typedef,
unless you were just trying to indicate that the variable you declared was unchanging, which
const does just fine.

Code:

typedef struct Foo {
    int x ;
} Foo;

Foo foo;
const Foo cfoo;

typedef int * IntStar;

IntStar iptr;
const IntStar ciptr;

void
test(void)
{
    int dummy;

    foo.x = 1;
    cfoo.x = 2;

    iptr = &dummy;
    ciptr = &dummy;

    *iptr = 0;
    *ciptr = 1;
}

Compilation:

Code:

$ gcc -std=c17 -Wall -fsyntax-only cc.c
cc.c: In function ‘test’:
cc.c:19:9: error: assignment of member ‘x’ in read-only object
  cfoo.x = 2;
         ^
cc.c:22:8: error: assignment of read-only variable ‘ciptr’
  ciptr = &dummy;
        ^

In general, though, I disagree with your sentiment. A pointer type should be typedef'ed if the pointer is the type. When you're allocating an array of objects, and intend to iterate through the array possibly using a pointer, the pointer is not the type -- the object is the type. And so you should typedef the object and use Object * for the pointer.

But when you're returning an opaque object that happens to be a pointer, and it's nobody's business what's behind the pointer, then by all means typedef the pointer. Consider for example the stdio type FILE. I've never written application code that dereferences or accesses through a FILE *. In a modern C library rewrite, FILE * should be typedef'ed to File or file_t something, since it's opaque and nobody really needs to know what's behind it. If all you do is pass them around, you can certainly hide the pointer-ness in a typedef.