In terms of C standards...

>unsigned char pointer
The chars need to be unsigned?

Some computers are still big endian. Floats aren't necessarily stored in the same bit order as ints, even though in practical terms they are.

So, prior to C99 - in the absence of strict aliasing - would the code be considered unspecified (rather than undefined) behavior, since the target platform doesn't leave any ambiguity about the bit order of floats and ints? Or would it still be considered UB?

Seems like it was UB even in C89:
stackoverflow.com/a/6514750

Leave it to cniles to be ignorant of the difference between how floating-point and integer values are stored in memory.
It should be plain as day why interpreting a float as an integer is meaningless.

Its a meaningless operation. C is not machine code and you cannot assume any behavior from those kinds of hacks.

Thanks for this!

Read the standard, faggot. From its purview, does it really make sense to do this? Where is the guarantee that they have the same representation?

*overflows your buffers*
heh... nothing personnel... kid...

Learn to code

I think you probably missed the point of what I was asking. gave me the answer I was looking for. I am not an experienced C programmer, and I didn't write the code in the thumbnail, it's the fast inverse square root function from Quake III Arena, I figured most on Jow Forums would recognize it.

Before you posted this thread, were you wondering whether the operation should be considered unspecified instead? There is no guarantee that there is an integer with the same binary representation as the float you are trying to convert. What does the machine do then? That's why it's UB. Even such a guarantee might not be a sufficient condition.

Because pointers have types dude.

In a sane language this would be flat out illegal

>There is no guarantee that there is an integer with the same binary representation as the float you are trying to convert.
Wouldn't that only apply to implicit conversion though? Isn't it expected with explicit conversion that there is no guarantee of a matching representation between types?

I hate computers. I'm glad we have better abstractions to instruct them today.

Bluepilled. Do you glow in the dark?

Are you asking rhetorical questions just for my attention?

Learn Malbolge, faggot.
>inb4 it's retarded
Learn to code.

This isn’t explicit conversion. What’s being reinterpreted is the pointer type, but the underlying representation is unchanged. You are asking the computer to go to this address and read a float, but what is actually there is an integer.

And floats are stored in FPU specific registers (xmm) as well, I guess that would also add more complications.

Lurk more, summerfag.

That's a yes.

In a "sane" language you would have gotten 5 FPS max when this calculation was havily used.

What is actually there is 32 bits of binary data, you fucking monkey. It a reinterpret cast.

Binary representation of floats and ints make the outcome totally platform dependent. And depending upon the aliasing integer type it may involve slicing or unaligned access. In a hypothetical architecture floats might be stored independently of integers, or involve reading cache from a separate coprocessor which isn't always possible. Its possible that a floating point type is just a couple of ints with a bunch of software-defined operations. What the fuck do you do then?

C tried to make as little assumption about future architectures as possible. Of course today we all know that computers are byte addressable twos complement integer processors with *potentially* co-stored/scheduled floating point processors (no coprocessor with separate cache). And with that convergence we can make assumptions. C++20 will remove a lot of UB related to signed integer representation. Two's complement is the one true representation.

shh fizzbuzzer, mommy and daddy are talking. meanwhile go read about what compile-time means.

Nothing in the standard requires a float or integer to be 32 bits.

True. I should have ommitted the 32-bit part. Either way my point still stamds. There's no 'integer' behind the pointer. It's just binary data.

dumb smelly NEET not knowing what the fuck he is talking about as usual
DOOM engine relied heavily on this calculation and sqrt to this day is still among the slowest operations to this day, this hack reduced that shit to a few FP multiplications a shift and a substraction.

This is making assumptions about alignment. There is no guarantee the int will be aligned such that it would be valid to dereference a float at that address.

No, what you're doing is making assumptions about alignment. What I'm saying is that when you dereference a pointer, you just get data back. No float, no int, just data. Memory doesn't keep track of data types and so your statement
>but what is actually there is an integer.
is misguided.

That hack stopped being relevant decades ago, when we got the algo in RSQRTSS.

You're programming against the C abstract machine as defined by the standard. You are not getting anything but UB.

You are making assumptions about what the compiler will do to your code beforehand. This isn’t assembly, your program might read data or it might alignment fault, or the compiler might just omit the code entirely because it’s UB.

because there isnt any guarantees about the relation between sizeof(float) and sizeof(long)
you could be reading invalid memory

See . There is nothing stopping an implementation from representing integers using a /proper/ subset of the space spanned by 32 (or however many) bits. If the 32 bits does not represent a valid integer, what then?

See, such shit shouldn't be allowed in the first place, since it doesn't make sense conceptually. Also this: If you for some bizarre reason allow it, the behavior will be necessarily undefined, as there is no guarantee that the ways those values are stored are compatible (usually they aren't).

Yeah, let's just go back in time and tell the id software guys that they are so dumb for not just using RSQRTSS
dumb smelly NEET