Lit. Buffer overruns 1709

Hm! Because I often have that "two people divided by a common vocabulary" feeling in reading your posts.

True enough -- I was using "allocate" to talk about how a program manages its address space (and in that context one can talk about static versus dynamic allocation, stack versus heap, etc.), but of course that's the application-program view, and there's also the OS view ....

snip

I'm having a hard time imagining a situation in which the OS isn't ultimately responsible for which processes have access to which parts of physical memory. But maybe there are circumstances in which non-OS processes can be trusted to do that themselves. Most of what I know about operating systems comes from undergrad-level textbooks, plus my vague recollections of dabbling in mainframe OS code many many years ago. The principles seem not too difficult to understand, but perhaps "the devil is in the details", as they say. (I think there's an example of just such a detail below.)

Oh. Okay. Different problem, then.

Are there any choices other than "tell the requesting application 'no way'"?

Why do I suspect that the situation you describe above is one that doesn't always occur to someone trying to write code for "pick a process to swap out" -- with bad results? :-) "The devil is in the details"?

I still don't get what you're saying -- I mean, from the application program point of view does it really matter *why* the OS won't give you the memory you requested (none available, limits set by you, limits set by OS, etc.)? shouldn't you mostly be concerned with just checking, after you ask for some memory, that you actually got it? which of course carelessly written programs don't always do.

However, I'm remembering that in some other branch of this thread there was mention of operating systems that "overcommit", meaning (if I understand right) that they sometimes grant requests for memory in such a way that when the application program tries to access the memory, it's not there.

Now *THAT* would be a situation in which even a carefully-written program could come to grief.

(I have to say that I find this rather shocking behavior on the part of the OS. But perhaps I lack an appreciation for how in the real world sometimes performance matters more than "correctness"? My idea is that it doesn't matter how fast something runs if it doesn't give the right answers, but that may be naive.)

Say whaaa ....? I have no idea what you're talking about here. Is this something you do as a user running programs that might overflow buffers, or something you can in coding the programs, or what?

And I'm saying that they almost certainly *will* be told -- it seems almost certain that they'll encounter the cryptic error message, and one way or another find out what it means.

Sure. But as I said above, it seems overwhelmingly likely that most students will at some point write a program that fails with the cryptic error message, and -- well, yeah, many won't buttociate that with some lecture they heard weeks ago, but they'll ask the instructor or their friends or someone, and *then* they'll make the buttociation. And the more time and frustration is involved in getting from the cryptic message to the source of the problem, the better they'll remember. :-)

Unfortunately, even then they're apt to be sloppy about putting in good error checking. Hm, maybe that means that eventually the memory fades of how they spent hours researching the cryptic error message, and it turned out to be an out-of-bounds access .... Maybe it takes several of those experiences to really get the point across. For a while I worked as a maintenance programmer on a moderately big and complicated program, and when you spend enough hours tracking down bugs in other people's code that turn out to be out-of-bounds access ....

snip

Not a problem!

Well, now I'm going to have to go back and find out exactly what it was I asked -- I vaguely remember that there *was* a question related to the formula E = m c^2, but that's about all I remember, and the formula you quote seems sufficiently different from the familiar one that .... Why do I suspect that digging that post out of Google's archives, with the new! and improved! interface might be tedious. My problem, though!

Anyway, thanks for going to some extra trouble.

-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.