It depends on what other people's code will do with those types. As a user of your library, if I assume that some_structure_t is a struct instead of a pointer to a struct, I might do something like this:
some_structure_t *p;
p = malloc( sizeof *p);
memcpy( p, &another_p, sizeof *p);
Maybe it's my background as an embedded programmer, but I want to know more about some_structure_t
in my code that uses it. Even if it's a truly abstracted type, and it's only used as a parameter or return value in end-user code, you still have to deal with it in the library that supports the type. If I saw the following code, I'd do a double take:
some_structure_t some_function( some_structure_t foo)
{
some_structure_t retval;
retval = malloc( sizeof *retval); // assigning pointer to struct?
retval->member = foo->member; // using -> instead of .?
return retval; // returning potentially large structure on stack?
}
And maybe this is the biggest one -- copying from one some_structure_t
to another. If it's an int
or a float
or a struct
, writing foo = bar
will make a copy. If some_structure_t
is defined as a pointer to a struct, now foo
and bar
point to the same object. Maybe that's what you want, but it seems risky to me.
I wonder if MISRA has anything to say about typedefs that are pointers.