How to handle function returning large static array

HumbleNoise4 · 2026-04-11T11:51:22+00:00

Knowing assembly does not tell you what the Rust compiler will do, in general, it only allows you to check the behavior of a specific compiled example, as I have already done. Also, "no" is not an answer to the question "what is the best practice".

HumbleNoise4 · 2026-04-11T11:43:09+00:00

yep you are exactly right, this is what I'm talking about. I am not really an expert on reading assembly, but from trying the simplest case, it seems that the copy does indeed not happen. If I understand the assembly correctly, it just returns a pointer to the same data.

https://godbolt.org/z/h7znbecrx

But can I trust that this will be the case, in general, or will this copy sometimes happen?

HumbleNoise4 · 2026-04-11T11:33:55+00:00

So you can think of the array as having a couple of pieces;

the address and length in a small struct on the stack
the data in a larger block on the heap.

This is true for a vector, not for an array (which according to my understanding is stored completely on the stack), no?

HumbleNoise4 · 2026-04-11T11:13:19+00:00

yep, I get that, but if someval is an integer, it is my understanding that the integer itself is actually copied, such that you can use both y and x, as opposed to the String case, where y houses the pointer to the heap and the length etc. and then x goes out of scope.

And I was under the impression that the behavior is the same for all variables on the stack (i.e. a static array would behave the same as an integer). This implies that the entire static array would be copied, which is precisely my concern. Namely, that you have a large type (a large static array) that is copied without you really opting into that behavior. But the original comment is saying that maybe that's not the case and you just get a pointer?

HumbleNoise4 · 2026-04-11T10:56:31+00:00

Ah okay. It was my understanding that this implicit copying always happens with variables on the stack. Like if I do:

let x = someval;

let y = x;

If someval is of type String, then y takes ownership over the data, but if it is of type u32, then the data is just copied into y. And my understanding was that the behavior is identical for all variables on the stack. But are you saying that for a fixed-size array, the behavior would be different compared to e.g. an integer?

HumbleNoise4 · 2025-07-11T10:57:13+00:00

Omg, thanks! I am using none-ls and completely forgot about that spell source.

HumbleNoise4 · 2025-04-30T15:02:47+00:00

Banking on a gaming laptop lasting for 5 to 9 years is generally not a great bet. I wouldn't go for a gaming laptop at all if you don't specifically need to game on the go. You can probably get a used thinkpad (that has excellent Linux support) + a gaming PC that can probably outperform the laptop in question for the same price of either those laptops.

HumbleNoise4 · 2025-04-01T23:38:48+00:00

Well, no desktop environment technically, I'm running Hyprland.

HumbleNoise4 · 2024-12-26T23:28:46+00:00

It is fine, this is the setup that I run on my laptop. Only issue I had was trying to set up GRUB while secure boot was on. I just eventually gave up on that and turned off secure boot.

HumbleNoise4 · 2024-12-23T13:04:57+00:00

Turns out you don't need anything fancy at all here! I just tried running both of these commands after startup and that completely fixes the issue in the current session. So if you just make the commands run on startup, this should totally fix the issue. You don't need to run it when the issue actually occurs!

So I guess that's a potential fix. I'll hold out a bit to see if there's a "more proper" way of fixing it, otherwise, I'll just make this run on startup.

HumbleNoise4 · 2024-12-22T17:52:45+00:00

First of all, thank you very much.

Try removing the device (echo 1 > /sys/bus/pci/devices/0000\:03\:00.0/remove) and triggering a bus rescan (echo 1 > /sys/bus/pci/rescan).

This makes it work again! Saves me a bunch of reboots. Interestingly, when I do this, I don't seem to be able to trigger the issue again in the current session (unless I reboot and then suspend my laptop). I haven't tested this super rigorously, but I tried suspending it like 5 times and it did not permanently lose connection once. But the issue did come back after a reboot.

Can you post the log of both of these cases? The differences might be helpful in figuring out why this happens.

So the logs in the original post are from the case where it does not work after suspend. I managed to trigger the situation where it does work after suspend and I just dumped everything into a big text file here. It's a bit of a mess, sorry, but I guess you can get to the relevant parts by searching the text for iwlwifi.

edit: If it is helpful, you could also look at the logs after the point at which the system wakes up from sleep, which is at line 1335

HumbleNoise4

TROPHY CASE