3 ms·

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

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.

monocasa 8y ago
As someone who's been paid in the past to write shellcode, stuff like that paid my bills.
- sifoobar 8y ago
  I'm pretty sure it was the same old regular buffer overflows as always. Which begs the question, what are you aiming for here?
  - monocasa 8y ago
    A lot of the time, simply overflowing a buffer like you would in the 90s doesn't cut it thanks to all of the mitigations built in these days. Finding code that completely forgets the shape of it's data really helps get the job done though.
kazinator 8y ago
The classic C90 version of the flexible array member (called the "struct hack") works fine in C++. So does the standard offsetof macro as well as containerof. The classic struct hack looks like: struct header { size_t size; char data[1]; // not [0] }; the size of the structure to just before data is offsetof(struct header, data). 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; a custom allocator or allocator wrapper will return a pointer to 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 GNU C++ compiler has a cool feature: -Wold-style-cast. With this I can pinpoint uses of the casting notation, and then replace them with these macros. 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.
- sifoobar 8y ago
  It's only a hack in C++ these days, from C90 it's standardized. 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.

monocasa 8y ago

As someone who's been paid in the past to write shellcode, stuff like that paid my bills.

sifoobar 8y ago
I'm pretty sure it was the same old regular buffer overflows as always. Which begs the question, what are you aiming for here?
- monocasa 8y ago
  A lot of the time, simply overflowing a buffer like you would in the 90s doesn't cut it thanks to all of the mitigations built in these days. Finding code that completely forgets the shape of it's data really helps get the job done though.

kazinator 8y ago

The classic C90 version of the flexible array member (called the "struct hack") works fine in C++. So does the standard offsetof macro as well as containerof. The classic struct hack looks like: struct header { size_t size; char data[1]; // not [0] }; the size of the structure to just before data is offsetof(struct header, data). 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; a custom allocator or allocator wrapper will return a pointer to 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 GNU C++ compiler has a cool feature: -Wold-style-cast. With this I can pinpoint uses of the casting notation, and then replace them with these macros. 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.

sifoobar 8y ago
It's only a hack in C++ these days, from C90 it's standardized. 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.