I'll repeat this here. Automatic void casts, flexible struct fields and calculating offsets to find the containing struct given a field are three things that I use all the time in C. Last time I checked, C++ wasn't very impressed by either one.
The classic struct hack looks like:
struct header {
size_t size;
char data[1]; // not [0]
};
Automatic void casts are a misfeature in both languages; more so in C. In code that I control, I use a pointer to a character type as an "any memory" type, so that it requires a cast in both directions:
E.g.
typedef unsigned char mem_t;
I use macros for casts, which compile to the classic C cast in C, and the more restricted casts in C++:
#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif
The stupid void star thing and its conversion rules should never have been invented. C++'s treatment of it is more sane, at least, by working without a cast in only one direction.
What's really awful is official API's that use void star for opaque handles. The Kronos Group's OpenMax is one of these. You can mix up different kinds of handles for different objects and the calls will compile.
That's like your opinion, plenty of C programmers worth their salt would disagree with you.
Look, I'm not saying it's impossible to write code that compiles both as C and C++. The same is true of many other languages. The point is that you can't write C and expect it to be valid C++, which was the only thing I claimed.