[vrtx0]

x20 is a general purpose register; optimizing compilers can use it for any number of variables, immediate values or intermediate computations at different points within that same function — or none at all (the variable ep could be optimized away).

Re: fork(), I just meant to be thorough in explaining the environment is copied, not shared by processes. Setenv() only affects the process from which it’s called.

The array size bit in the article: The value 0x220 looks suspiciously close to the size of the old environment in 64-bit words (0x220 / 8 = 68), and this value was written over the terminating NULL of the environment block…

HTH!

[saagarjha]

No, it does not. I don't think you understand what you are talking about, because none of these actually address the points I brought up. They use the same words, but semantically they are talking about something completely different.

[vrtx0]

I provided a copy/paste from the site about the envp array size you asked about.

I clarified why I mentioned fork().

I tried to explain the difference between registers and variables.

I’m not trying to show off or bring anyone down… I just like to help people. I’m old (my first Linux kernel commit was in 2004). And I could be wrong — please LMK if I made a factual error (I’d appreciate it, honestly).

All good?

[saagarjha]

I am going to do this once, but not again. Please pay attention to it. You are not just wrong, but failing to demonstrate an understanding of the actual topic being discussed. I can't say whether you actually have it or not, but your responses do not demonstrate this. I have dealt with plenty of people on this site who say things that are factually incorrect, many of whom have argued with me when I do so. You are not doing that; rather you are not even understanding what I am saying.

The article specifically mentions that the authors consulted the disassembly to see what was in x20. I know it is a general purpose register. They know it is a general purpose register. This knowledge is completely irrelevant: they read the code, they matched it against the actual source, they can confirm that at the time of crash x20 contains what they said it contains. The compiler optimizations have already run. They can't change anything anymore. That you mentioned this shows that you do not follow the actual order of events here.

envp, similarly, is in the process of being operated on in the crashing code. The authors grabbed its size from some random context at the time of the crash. The fact that it is not actually stored in the array itself is completely irrelevant to the fact that its numeric value was present in the crash dump. Obviously, some code that operated on it had computed the value and stashed it, which is a completely natural and expected thing for this code to do.

Finally, nobody cares about setenv across processes. The article didn't talk about this. It's completely irrelevant to mention this, and in fact there is another comment further down (which you may not have read, I'm ok with that) that also has the same confusion and it belies a poor grasp of what the actual problem is.

You can see that I am forced to do significantly more work than you to respond to what specifically is the problem here. It looks like you are pattern matching on specific words and then regurgitating your knowledge on it, whether it is relevant or not. When it's not, it's essentially just spam; when it is you fail to actually take into account the content that is actually being discussed. When I'm talking about how I almost got run over by a driver on their phone you are not welcome to step in and start talking about how a lot of hit-and-runs involve drunk drivers. I wasn't talking about a hit-and-run, and I just told you the person was on their phone. Somehow you completely missed that and kept talking about what you wanted to mention, like if you gave the gist of the conversation to someone else and asked them for their response on it and then pasted that here without checking to see if it was relevant or not. Don't do that.

[mad0]

Sounds like you are arguing with a bot? em-dashes are a giveaway (nobody sane uses these "—")

[saagarjha]

My policy about interacting with a person using a bot is actually the exact same as it is when interacting with someone who writes their own comments. This is actually very convenient because it completely eliminates any arguments about whether or not they are using an LLM or whether I have some sort of "bias" against them. My core argument is this: I treat the content coming out of it as being said by you. In this case the comments were of substandard quality. If the user was writing them by themselves, then the hope is that they will read my message and realize why and improve themselves in the future. If it was done by consulting something else, the idea is that they should reconsider the quality of its output. Either way, they're the one who comes out of it looking poorly.

[msully4321]

I go through periods of loving em dashes--but I always just write them as two dashes! (And LaTeX at least does the right thing.)

[dboreham]

Is it possible you're replying to LLM generated posts?

[saagarjha]

Of course. The reply remains relevant either way.

[9rx]

Would it matter?