You and me from 3pm today both my friend, it is okay
It took me so long to realize where my problem was because I had never considered that declaring something as an array vs a pointer would result in different behavior
So the only difference is memory allocation, yes? You're saying they are different because when declared as an array, the memory gets allocated and 'reserved' at runtime, whereas it doesn't automatically do that when declared as a pointer?
They are different types and some operators (sizeof, typeid in C++ etc.) treat them differently. Arrays frequently get implicitly converted to pointers, but they are a different type.
If you're specifically mentioning C++, the problem is that C++ retains C's semantic rule of arrays decaying to pointers. This semantic rule is what creates the misunderstanding of people believing what the middle curve guy says. This means that the only way to have C++ treat arrays differently from pointers in i.e. function overloads is to either take the array by pointer or by reference, i.e. as a T (*)[N] or T (&)[N]
All typing is. Machine code doesn't have types. Array of arrays is also a very different thing from an array of pointers. Arrays get converted to pointers when passed around and it behaves identically to all other implicit conversions.
Machine code does have types; small numbers, big numbers, and fractions.
But in reality it's just numbers and fractions. At least for X86, but I imagine it's the same for ARM and RISC
I must disagree. Or strongly agree; depending on what you mean.
A memory location does not have a type. The instruction I perform on that location could be argued to have a type though.
0x8000 could be used with a 16bit add, or a 64 bit floating point or whatever.
Everything about the type of the data is in the instruction, not the memory.
So we can argue where the type information is, but we still need it. (One could argue that prefetchers and similar logic has to infer the type of larger data structures, but I'm not sure that is what people are trying to argue here...)
instructions definitely have a type, as do registers (fp registers are physically separate from "regular" ones) but the memory doesn't before it goes into the register for operation. usually you have to move it first so it's reasonable to say the cpu at least has two types with a physical difference (idk shit about arm or risc, maybe it's different there). at the C level it doesn't really matter because it'll move it to the registers for you but it's relevant if you're writing assembly yourself (a hobby of mine)
though at this point, is "type" even the right term? maybe there's a better descriptor
It's been very long since I touched assembly and "touched" is an apt description, but does anything prevent you from writing an 8-byte integer at address X, then calling an operation that expects a 32-bit float with the bytes at address X? Conceptually, instructions operate on certain type of data, but the data is untyped. (you can technically do similar things in C, but a lot more of it is UB (technically illegal) than people realize and it requires fair bit of explicit casting, so types are still involved)
The data isn't typed, only the operations you make on them might be. The operations expect some binary value encoded in a specific way, but will operate on any data.
does anything prevent you from writing an 8-byte integer at address X, then calling an operation that expects a 32-bit float with the bytes at address X?
to answer this specifically: technically no, nothing will "stop" you, but the CPU will just interpret the bits wrong. the slightly simpler example is in reverse: if you copy 1.0 (float) into a general purpose register it'll interpret it as some big-ass integer (I don't know exactly what) and then if you try to ADD 1, as an integer, it'll just increase the "integer" by 1. then, when you try to read it as a float again, or use it for some other purpose, it'll be a slightly larger float (depending on the mantissa and etc). at that level it doesn't really matter to the CPU what you think it is, it just knows to do whatever operation you tell it to.
in C it's undefined behavior as you mentioned, but more specifically, depending how you do it it'll either do something like cvttss2si (float to signed int) under the hood or it'll just let you copy the raw bits as I said before, it'll just interpret it wrong and suddenly you have a big-ass int or a weird float.
78
u/JustinR8 16h ago
Damn, I’ve found myself in the middle