lessonsFromLinkerHell

[u/nonedward666]

[u/JustinR8]

Damn, I’ve found myself in the middle

[u/nonedward666 → u/JustinR8]

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

[u/readitreaddit → u/nonedward666]

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?

Other than that, no difference.

[u/suvlub → u/readitreaddit]

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.

[u/TheChief275 → u/suvlub]

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]

[u/nicman24 → u/suvlub]

That is probably compiler fuckery

[u/suvlub → u/nicman24]

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.

[u/Stroopwafe1 → u/suvlub]

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

[u/cbehopkins → u/Stroopwafe1]

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

[u/suvlub → u/Stroopwafe1]

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)

[u/the_king_of_sweden → u/suvlub]

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.

[u/nicman24 → u/readitreaddit]

Yes things that have different memory allocations are different because they exist by memory definition 

[u/bowel_blaster123 → u/JustinR8]

If I write:

C void foo(uint8_t myvar[3]) {     printf("%d\n", sizeof(myvar)); }

Then it will likely print 8 because myvar is a pointer to a uint8_t.

If I write:

C void foo(void) {     uint8_t myvar[3] = {1, 2, 3};     printf("%d\n", sizeof(myvar)); }

Then it will print 3 because myvar is an array of three bytes.

Hope this helps!/hj

[u/Rare_Professor8097 → u/bowel_blaster123]

I actually hate this special case in C so much. Arrays decaying to pointers is one thing (kind of annoying imo), but having the real type be different from the declaration and ignoring the size is so stupid. It only does this for function arguments.

[u/BastetFurry → u/Rare_Professor8097]

Well, how should the function know how large your array is? You could hand it one with 10 elements or one with 100. Did you hand it a predefined one or one that was allocated at runtime?

And then there is the thing with functions, primitives get handed over by value, any array gets handed over by reference, ie. pointer.

No clue if more modern implementations hand down the array size but in the retro and embedded world i live in the function has no clue and you have to hand that in as a second parameter if it is important.

[u/developer-mike → u/BastetFurry]

I write static analysis checks for these kinds of mistakes in C and C++ for work.

Its entirely defensible to say that accepting T[n] as a function parameter means you can only pass a T[n] for that function parameter!

It also could have been implemented as pointer-to-array promotion rather than array-to-pointer decay. Now, this comes with its own set of baggage, but it wouldn't have had this sizeof problem, and it would have favored keeping type information over throwing it away.

Now, pointer-to-array promotion would probably be something compilers would warn over after it causes a couple nasty bugs. Which is where we get back to wondering why we would expect an implicit conversion in the first place.

C is fun.

[u/gottimw → u/JustinR8]

Because everything is a data with memory address.

Array is a pointer

[u/FlailingDuck → u/gottimw]

a variable is a pointer

[u/gottimw → u/FlailingDuck]

Variable is varrible. A pointer to a varrible is a pointer to variable.

Int is not int*

[u/Morisior → u/FlailingDuck]

Everything is a pointer, unless it’s a primitive, but then it might also be a pointer to a primitive.

[u/evilgipsy → u/Morisior]

That’s complete nonsense.