5 ms·

> If your C compiler doesn't complain bitterly to you about an incompatible pointer type on that assignment, get a better C compiler. The example code uses C s

> If your C compiler doesn't complain bitterly to you about an incompatible pointer type on that assignment, get a better C compiler. The example code uses C style casts, which is C-speak for "fuck off compiler I know what I'm doing." I'd like to see what warnings your compiler produces. VS2015 /W4 /ANALYZE produces nothing, and neither do clang nor GCC from the looks of it. That people C cast without knowing what they're doing is rather unfortunate tragedy. That this is a common enough problem, that the Win32 API is littered with backwards compatability hacks where someone C-casted away ABI differences turns it into a statistic. > If you write this in production code, and don't get sent home that day in tears, your company's code review process has failed. Assuming we're talking "well meaning newbie" instead of "sanity hating self-flagellating freak and/or undefined behavior worshiping cultist", I prefer to carefully explain that they've invoked undefined behavior, that undefined behavior leads to crunching to find optimizer induced heisenbugs in the weeks before we ship, and to impress upon them that this is why we never cast away even "trivial" and "minor" function pointer differences. And then, when they ask what the correct thing to do is, point out the API docs and header both have this little "WINAPI" annotation they can use. Hey! No more casts! Easier than the casts too. Win/win. However, if we are talking about the "sanity hating self-flagellating freak and/or undefined behavior worshiping cultist", I can only recommend nuking the site from orbit. It's the only way to be sure. If their home isn't part of the radioactive crater, you didn't use large enough nukes, and your company's code review process has failed.

quotemstr 10y ago
I'd hate to work at a company with a blanket prohibition on dirty tricks like this. On rare occasions, there are good reasons to use hacks, and I'd hope my coworkers would at least be open to an attempt at justification. Sometimes silly newbie mistakes actually end up being the right thing to do in rare, specialized circumstances and in experienced hands.
- wahern 10y ago
  I can't ever imagine a scenario where a hack _like_ _that_ is acceptable. If you need something like that, just drop down to assembly. It's more portable (in the sense that you're coding to an interface), infinitely more clear about what you're doing and and how you're doing it, much less likely to break, and when it does break is likely to break loudly. Even if you've never done a lick of assembly programming (I haven't done much) it'd still be infinitely preferable, even if you had to support a dozen architectures with two dozen different function proxies. "Hack" is a very broad term. By some definitions a significant chunk of extant code qualifies as a hack. But whatever the definition, a hack still implies some quantum of legitimacy. There's nothing legitimate in using function type punning as a way to reorder or control argument values. Not unless this was 1969, where there was precisely one C compiler, used by precisely one guy, and where such code was expected to be thrown out in short order, never to infect code that executed in other than identical circumstances.
  - caf 10y ago
    The reordering thing is bunk anyway, because if you just define the reordering function: double IntPowerOfDouble(int power, double base) { return DoubleToTheInt(base, power); } ...then gcc with -O1 will optimise IntPowerOfDouble to a plain "call DoubleToTheInt", and with -O2 will completely inline DoubleToTheInt into it.
- munchbunny 10y ago
  Dirty tricks are almost never worth the long term technical debt they represent when either (1) weird bugs start showing up or (2) the original author leaves the company. I used to believe that there were times when dirty tricks were the right call in certain cases. The problem was that the long term view always proved me wrong: a more verbose but commonly understood approach is much more maintainable than a concise dirty trick, even with ample commenting and documentation.
- MaulingMonkey 10y ago
  > On rare occasions, there are good reasons to use hacks Yes. However. If you wish to convince me that any of the type punning examples from the article, as given, are useful in production code, I will allow you that opportunity. But only after I've had the chance to make myself a bowl of popcorn large enough to share with whoever else might be entranced by the ensuing trainwreck.
- buserror 10y ago
  And there are different version of 'dirty trick' perception too. Sometime what people perceive as 'dirty trick' is just normal use of the language while the muggles want to talk baby talk all the time. For example, having to explain the functional use of 'x = !!variable' to a C programmer. There are many like that. Sometime you just have to decide to raise the bar a little...
  - pklausler 10y ago
    I used !! for decades, but since C'99, I've recommended "bool x = variable" or "(bool) variable".
    - yoklov 10y ago
      The reason I would prefer !! (or != 0) is that there are far too many err, non-bool bools. Even if you know for sure it's the stdbool.h bool, the next reader might not be aware -- presuming that when you do this you care about the distinction (otherwise I agree that the cast is fine).
rbanffy 10y ago
> your company's code review process has failed. I often remind my fellow engineers to keep their code muggle-friendly. And, mind you, our code base is mostly Python, a language that actively avoids black magic by design.
- cousin_it 10y ago
  > keep their code muggle-friendly What a great phrase, I'm going to borrow that.

quotemstr 10y ago

I'd hate to work at a company with a blanket prohibition on dirty tricks like this. On rare occasions, there are good reasons to use hacks, and I'd hope my coworkers would at least be open to an attempt at justification. Sometimes silly newbie mistakes actually end up being the right thing to do in rare, specialized circumstances and in experienced hands.

wahern 10y ago
I can't ever imagine a scenario where a hack _like_ _that_ is acceptable. If you need something like that, just drop down to assembly. It's more portable (in the sense that you're coding to an interface), infinitely more clear about what you're doing and and how you're doing it, much less likely to break, and when it does break is likely to break loudly. Even if you've never done a lick of assembly programming (I haven't done much) it'd still be infinitely preferable, even if you had to support a dozen architectures with two dozen different function proxies. "Hack" is a very broad term. By some definitions a significant chunk of extant code qualifies as a hack. But whatever the definition, a hack still implies some quantum of legitimacy. There's nothing legitimate in using function type punning as a way to reorder or control argument values. Not unless this was 1969, where there was precisely one C compiler, used by precisely one guy, and where such code was expected to be thrown out in short order, never to infect code that executed in other than identical circumstances.
- caf 10y ago
  The reordering thing is bunk anyway, because if you just define the reordering function: double IntPowerOfDouble(int power, double base) { return DoubleToTheInt(base, power); } ...then gcc with -O1 will optimise IntPowerOfDouble to a plain "call DoubleToTheInt", and with -O2 will completely inline DoubleToTheInt into it.
munchbunny 10y ago
Dirty tricks are almost never worth the long term technical debt they represent when either (1) weird bugs start showing up or (2) the original author leaves the company. I used to believe that there were times when dirty tricks were the right call in certain cases. The problem was that the long term view always proved me wrong: a more verbose but commonly understood approach is much more maintainable than a concise dirty trick, even with ample commenting and documentation.
MaulingMonkey 10y ago
> On rare occasions, there are good reasons to use hacks Yes. However. If you wish to convince me that any of the type punning examples from the article, as given, are useful in production code, I will allow you that opportunity. But only after I've had the chance to make myself a bowl of popcorn large enough to share with whoever else might be entranced by the ensuing trainwreck.
buserror 10y ago
And there are different version of 'dirty trick' perception too. Sometime what people perceive as 'dirty trick' is just normal use of the language while the muggles want to talk baby talk all the time. For example, having to explain the functional use of 'x = !!variable' to a C programmer. There are many like that. Sometime you just have to decide to raise the bar a little...
- pklausler 10y ago
  I used !! for decades, but since C'99, I've recommended "bool x = variable" or "(bool) variable".
  - yoklov 10y ago
    The reason I would prefer !! (or != 0) is that there are far too many err, non-bool bools. Even if you know for sure it's the stdbool.h bool, the next reader might not be aware -- presuming that when you do this you care about the distinction (otherwise I agree that the cast is fine).

rbanffy 10y ago

> your company's code review process has failed. I often remind my fellow engineers to keep their code muggle-friendly. And, mind you, our code base is mostly Python, a language that actively avoids black magic by design.

cousin_it 10y ago
> keep their code muggle-friendly What a great phrase, I'm going to borrow that.