PRE03-C. Prefer typedefs to defines for encoding non-pointer types

This might be enforceable by a static analyzer that could parse macro definitions and see that they refer to a valid typedef. ROSE can't currently do this, so we don't know how effective or difficult this would be.

in

typedef char *NTCS;
const NTCS p = &data;

Isn't p a "pointer to a const char" not "a constant pointer to char"?

While I agree with this rule in principle, in my opinion using a typedef for char* or any other pointer type is ill-advised because:

• applying the const or volatile qualifiers to the typedef has an unexpected effect (as mentioned in second paragraph of the recommendation and evidenced by the comment by Masaki Kubo above)
• doing so makes it difficult to see, at a glance, that the name refers to a pointer rather than an ordinary type

Both of these issues can lead to subtle and difficult to diagnose bugs. For example:

typedef char *cstring;

void f(cstring s) { s[0] = '\0'; }

void g(const char *s) {
    f(s);   // diagnostic: call discards const qualifier
}

// programmer misunderstood rules, thinks const cstring
// is the same as const char*
void h(const cstring s) {
    f(s);   // whoops! s modified, no diagnostic issued
}

Perhaps instead of using examples involving pointers it might be better to use structs instead. I.e., instead of the following non-compliant solution:

struct some_struct_tag { /* ... */ };
#define some_struct struct some_struct_tag

use the following compliant solution:

struct some_struct_tag { /* ... */ };
typedef struct some_struct_tag some_struct;

After thinking about this as well as first hand experiencing the same design flaw as the one that affects The Managed String Library discussed above, I'd like to change this guideline to:

• use something like unsigned char or long double as an example where typedef may be called for, e.g., instead of

  #define UCHAR unsigned char
  

  use:

  typedef unsigned char UChar;
  

  with a rationale analogous to that given in PRE00-C. Prefer inline or static functions to function-like macros, namely that textual substitution is inferior to using the type system, and
• either as an exception to this guideline, or in a guideline of its own, recommend against using typedef for pointers and give the interface of the Managed String Library as a Noncompliant Code Example.

If no one objects I'll go ahead and make these changes.

I would like to remove the DCL05-C issue with the CCE, but am struggling to come up with a compelling code example.  It would be trivial to use:

#define foo unsigned long
foo f;

But the existing code example is better at showing the dangers of using the macro over the typedef.  Ideas welcome!

This is not confusing at all. An personally I prefer putting const storage class specifier on the right of type.What typedef does, unlike #define that only expands the text, is to make a type alias.

So consider that :

const NTCS p;

is equivalent to

NTSC const p; 

The latter one is much more consistent ans easy to understand and will never cause confusion as read as "const pointer to char".

Yup. I was referring to the specific case above (typedef char * NTSC).

I mean by always having const storage class on right to the type, it will help enhance the readability and reduce the confusion, especially in production quality code. It also makes an obviously tip that : const storage class decorates the closest type left to it.

Is it necessary to split the CS into:

cstring s1;
cstring s2;

Testing under gcc 4.6.3, I got the correct result with just:

cstring s1, s2;

While this violates DCL04-C, I think that this better demonstrates the differences between typedef and #define behavior since it more closely mirrors the NCCS. As it is, the correct behavior of the CS could be incorrectly attributed to the declarations being on separate lines.