I don't see how there is a matter of correctness here, except inasmuch as yes, both typedefs you present are syntactically correct, and it is possible that a program would have use for both types.
As a matter of style, however, it is poor form to hide pointer nature behind a typedef. It very easily becomes confusing.
It is also a bit questionable to typedef anything as void *
-- it provides no type safety of any significance, and not much semantic assistance either. If you really want to accept a pointer to anything, then just say void *
. If, on the other hand, you want to hide the details of a struct type, then just declare the structure type as an incomplete type, and leave it that way:
struct Elem;
Optionally, typedef that for convenience:
typedef struct Elem Elem;
Personally, and again as a matter of style, I would prefer to see the const
keyword than to see a typedef that rolls in the const
, no matter how clearly designated.
Note also that all questions of style aside, this particular typedef ...
typedef const void* const constElem;
... seems of rather narrow usefulness. It designates a pointer whose value cannot be changed and that points to an object that also cannot be changed. A non-const
pointer to a const
object is much more often what you want. Note, too, that the uncertainty over what constElem
should mean is one consequence of rolling up pointer nature inside the Elem
typedef.