Angry C coder weaponizes pointer cast to brutally unfloat your float

Description

A meme on a solid black background features large bold white text across the top that says, "You know what? Fuck you". Centered beneath it is a dark-theme code snippet showing the C statement “i = *(long*)&y;”, where the variable ‘i’ is green, the keyword ‘long’ is blue, and the punctuation is light gray. At the bottom, equally large white text reads, "Unfloats your float". The gag is that the programmer angrily reinterprets the raw bits of a float variable by casting its address to a long* and dereferencing it, a classic type-punning hack that violates strict aliasing rules and triggers undefined behavior. The humor plays on low-level memory manipulation, unsafe code practices, and the perils of C’s permissive pointer arithmetic that senior systems developers know all too well

Common Tags

PointersInC UndefinedBehavior UnsafeCode CFamilyLanguages LowLevelProgramming CodingHumor TypeSafety MemorySafety

Comments

Anonymous ★ Top Pick Sure, C++20 gave you std::bit_cast, but the real greybeards still keep *(long*)&y around - nothing boosts job security like compiler-level Russian roulette

Anonymous ★ Top Pick

Sure, C++20 gave you std::bit_cast, but the real greybeards still keep *(long*)&y around - nothing boosts job security like compiler-level Russian roulette
Anonymous

This is what happens when you let that one cowboy coder who insists 'real programmers don't need type safety' near your financial calculations - suddenly your $1.99 becomes 1073741823 and accounting wants to know why the quarterly report shows the company is worth more than the GDP of Earth
Anonymous

This is the programming equivalent of telling your compiler 'I don't care about your type system, I'm reading these bytes MY way' - a power move that works until it spectacularly doesn't, usually on a different architecture at 3 AM in production. Senior engineers recognize this as the kind of code that makes you simultaneously impressed by the audacity and horrified by the implications, knowing full well that the next person to touch this will be debugging why their float calculations are returning the meaning of life, the universe, and everything (but as an integer)
Anonymous

i = *(long*)&y; works until -O3 and strict aliasing shake hands on LP64 vs LLP64 - std::bit_cast exists so you can sleep
Anonymous

*(long*)&y: unfloats your float, gaslights your debugger, and summons strict-aliasing demons - exorcised only by -fno-strict-aliasing
Anonymous

Type punning: C's polite way of telling the compiler to mind its own damn business
@ZgGPuo8dZef58K6hxxGVj3Z2 5y

Ahh yes the classic way of casting unmanaged data without conversion
@FLIPFL0P_T 5y

Practical example :D
@SuperiorProgramming 5y

Segmentation fault
1. @beton_kruglosu_totchno 5y
  
  how so
  
  @SuperiorProgramming 5y
  
  * a pointer operator and & address of operator right?
  
  @SuperiorProgramming 5y
  
  Dereferencing a casted pointer is illegal.
  
  @beton_kruglosu_totchno 5y
  
  >* a pointer operator and & address of operator right? Yes. >Dereferencing a casted pointer is illegal. If you mean the strict aliasing rule then basically yes but if you need it to be 100% correct you can make it correct or just disable strict aliasing rule in compiler. Linux is compiled with 'no-strict-aliasing'
  
  @SuperiorProgramming 5y
  
  So this doesn't create a segmentation fault? I think it touches a memory address that it doesn't have access to.
  
  @beton_kruglosu_totchno 5y
  
  1) There is a concept of undefined behavior in C and C++. Accessing a stored value by pointer of any type other than char is UB and your compiler can kick your ass with optimizations that assume this rule. This is the only reason why this code can cause problems and specific software can prefer to compile with 'no-strict-aliasing' and validly use this code. 2) But it won't ever result in segmentation fault in any scenario because interpreting memory region as a different type does not make the memory address invalid. 3) You can use union as an intermediate union { float f; long l; } This would be valid in all cases.
  
  @SuperiorProgramming 5y
  
  Thanks for a brief explanation.
  
  @cringy_frog 5y
  
  for me, the preferred way of avoiding the strict aliasing issues in such scenarios is to use memcpy: long i; memcpy(&i, &y, sizeof(long)); // assuming long and float have the same size unions have their own non-obvious pitfalls (like, you must read from the same member you've written to last time; reading from i when last written to f, IIRC, is not a standards-compliant behavior)
  
  @beton_kruglosu_totchno 5y
  
  My bad, I was totally unaware about the requirement to read from same member.
  
  Deleted Account 5y
  
  3 is not valid in c++, bc it violates object lifetime, the only way to type-pun a value in c++ (except using memcpy) is to use std::bit_cast
  
  @affirvega 5y
  
  I don't get it, how does it violates object lifetime? Shouldn't union be a single object?
  
  Deleted Account 5y
  
  union members in c++ are objects themselves, and accessing the inactive variant of a union means accessing an object, whose object lifetime hasn't started yet. There is a cppcon talk about about this problem, imma find it
  
  Deleted Account 5y
  
  https://www.youtube.com/watch?v=_qzMpk-22cc that's the video yea
  
  @affirvega 5y
  
  Thanks, imma check this out
  
  @affirvega 5y
  
  There's so many ways I can write UB code now, thanks xd
  
  Deleted Account 5y
  
  no problem))
  
  @rush_iam 5y
  
  if it is about Quake 3 trick - long and float are 32 bit in 90s
  
  @SuperiorProgramming 5y
  
  Another additional info, sweet.
Deleted Account 5y

yeaah❤️

Use J and K for navigation

Angry C coder weaponizes pointer cast to brutally unfloat your float

Description

Categories

Common Tags

Comments

More like this

C Pointers As RAM Landmines

When Programming Concepts Become Flirtatious Banter

C's One-Size-Fits-All String vs. Rust's Entire Wardrobe