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.

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.

What a great phrase, I'm going to borrow that.

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.

  double IntPowerOfDouble(int power, double base)
  {
      return DoubleToTheInt(base, power);
  }

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.

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.

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...

Another thing which makes this sort of thing difficult to warn in is the brokenness of autoconf. Autoconf checks that your system has memcpy (or anything that you check via AC_TRY_LINK) by compiling this program:

    void memcpy();
    int main() {
      (void)memcpy();
    }

However, the snippet above is still broken in that respect, because it doesn't match the return type of memcpy - and that is U.B.

Yes. And the call here does not match the types of the real parameters, even before we consider the return type.

> I guess they could have wrapped it in if(0){...} to make this completely unambiguous.

Depending on optimizations, that may mean the executable does not depend on the symbol we're trying to test the presence of.

Indeed, on my local gcc that's the case, even with -O0.

    $ cat test.c
    void *memcpy();
    
    int main() {
    	if(TEST) {
    		(void)memcpy();
    	}
    }
    $ gcc -DTEST=0 test.c
    $ objdump -T a.out
    
    a.out:     file format elf64-x86-64
    
    DYNAMIC SYMBOL TABLE:
    0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 __libc_start_main
    0000000000000000  w   D  *UND*	0000000000000000              __gmon_start__
    
    
    $ gcc -DTEST=1 test.c
    $ objdump -T a.out
    
    a.out:     file format elf64-x86-64
    
    DYNAMIC SYMBOL TABLE:
    0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 __libc_start_main
    0000000000000000  w   D  *UND*	0000000000000000              __gmon_start__
    0000000000000000      DF *UND*	0000000000000000  GLIBC_2.14  memcpy
    
    
    $ gcc -O0 -DTEST=0 test.c
    $ objdump -T a.out
    
    a.out:     file format elf64-x86-64
    
    DYNAMIC SYMBOL TABLE:
    0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 __libc_start_main
    0000000000000000  w   D  *UND*	0000000000000000              __gmon_start__
    

    $ cat test.c
    void *blah();
    
    int main() {
    	if(TEST) {
    		(void)blah();
    	}
    }
    $ gcc -DTEST=1 test.c
    /tmp/cc2Vk5mE.o: In function `main':
    test.c:(.text+0xa): undefined reference to `blah'
    collect2: error: ld returned 1 exit status
    $ gcc -DTEST=0 test.c
    $ objdump -T a.out
    
    a.out:     file format elf64-x86-64
    
    DYNAMIC SYMBOL TABLE:
    0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 __libc_start_main
    0000000000000000  w   D  *UND*	0000000000000000              __gmon_start__
    
    
    $ gcc -O0 -DTEST=0 test.c
    $ objdump -T a.out
    
    a.out:     file format elf64-x86-64
    
    DYNAMIC SYMBOL TABLE:
    0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 __libc_start_main
    0000000000000000  w   D  *UND*	0000000000000000              __gmon_start__

You definitely have a point regarding compiler just ripping that code out. I guess the proper approach would be to do something like if(argv[0][0]), or test a volatile variable.

Yeah? So which compiler do you have in mind exactly we should use?

gcc 4.8.4 on Ubuntu 14.04 Trusty still gives no warnings, but gives a different result:

  $ gcc -W -Wall x.c -lm
  $ a.out
  (0.99)^100: 0.366032
  (0.99)^100: inf

  $ clang -W -Wall -fsanitize=undefined x.c -lm
  $ a.out
  (0.99)^100: 0.366032
  (0.99)^100: inf

    ; gcc -v |[2] grep version
    gcc version 6.1.1 20160802 (GCC) 
    ; gcc -Wall -Werror ./something.c  -lm
    ; ./a.out 
    (0.99)^100: 0.366032 
    (0.99)^100: 0.000000 
    ;

And sometimes you need to do terrifying, nonportable, ugly hacks in order to get something specific to work. My own contribution to this field is an ARM stack unwinder that requires only one __asm__ inline in order to get the link register and does everything else by interpreting instructions.