Comment by kazinator | Hacker News Reader

Comment by kazinator | Hacker News Reader

Parent Full thread

> Many fundamental tricks that are routinely pulled in C require jumping through plenty of hoops to keep a modern C++ compiler happy.

Not in my experience. Currently my man open source project consists of some 70,000 of C which compiles as C++. Maintaining C++ compatibility takes very little effort. I tend to switch to C++ before a release, to catch regressions. Often there is nothing. The most I spend is maybe five to ten minutes fixing some minor things. Some of those minor things have nothing to do with C versus C++ like signed/unsigned warnings.

Note that these signed/unsigned warnings from GNU C++ actually found a real problem: I had code which assumed WEOF was negative. (It was originally char based code that was switched to wchar_t; of course EOF constant in the narrow character world is negative.) The GNU C++ compiler also identified the situation in the same code that a variable that should have been wint_t was mistakenly int.

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.

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

I'm pretty sure it was the same old regular buffer overflows as always. Which begs the question, what are you aiming for here?

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.

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.

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.

Reply on news.ycombinator.com