Lit. Buffer overruns 1707
 |
snip
I'm having flashbacks to the days when I, a junior person doing mainframe systems-level programming, struggled to communicate with the people in the machine room ("operators") -- both of us seemed to have areas of expertise, but somehow their technical vocabulary and mine didn't seem to overlap very much, and the result was much frustration. (I'm sure it didn't help that I was young and female and they were generally older and male. I didn't know much, but I probably knew more than they thought I did.) I think we have something like this going on here -- two specialists divided by a vocabulary that seems common but isn't? -- but maybe not. Back to the discussion.
Okay, when I said "space allocated and controlled by a program, usually an application program" -- yeah, rather than "allocated" maybe I should have said "requested from the OS", because I am aware, if perhaps not in detail, that it's the OS that's typically responsible for deciding which processes-programs have access to which physical memory. If it doesn't do that correctly, yeah, that's not good. Programs can overrun buffers internally (and trash their own data), or can attempt to access memory they don't own (and -- one hopes! -- get slapped down by the OS). I'm guessing that by "underrun" you mean falling off the low-address end of a buffer, where "overrun" is falling off the high-address end, and if so, sure, both are problems. I'm not quite sure how deadly embraces come into this discussion -- seems like that's more of a problem in managing concurrency -- but okay.
some number of years ago, netscape store was the largest ftp site ... they were having to do round-robin dns and router...
They don't but I'm only there, I don't have time for afc, sorry.) RT-11 didn't, and couldn't because it ran (mostly?) on models without memory Debt Management (hence protection) or...
No idea what you mean here. My thinking is that a carefully written program keeps track of how much memory it has requested from the OS, and whether the request was granted, and it doesn't try to use more-different memory than the OS gave it. And you're saying it can still run into trouble? through flaws in the OS? hardware problems?
Well, with a language that doesn't do bounds checking, you aren't going to get a nice obvious error message like "buffer overflow, you idiot!" Instead you're going to get either a possibly-cryptic error message-code from the OS telling you the program tried to access memory it didn't own (well, with a reasonably sophisticated OS -- I once found out the hard way that MS-DOS in its early form didn't try to defend its own data areas from application programs, and was *that* ever a learning experience, after years in the mainframe world), or .... Well, when you overflow a buffer, but not so badly as to go outside your program's buttigned memory, the result is likely to be the trashing of some data area unrelated to what you thought you were doing, and the symptoms can be pretty much anything, including the security problems that were the initial subject of this thread. If the OS slaps you down, well, I claim that even relatively inexperienced programmers quickly learn to buttociate the cryptic error message with what they've done wrong. (I teach second-semester programming, so I have some basis for this claim.) Realizing that other problems can be caused by just slightly overrunning a buffer (and thereby trashing some of your own data) takes longer.
But in any event, I would claim that the simplified mental model of memory that we teach in first-semester programming ("think of your program's memory as a really really long list of fixed-size cells ....") is enough for the students to get a pretty good idea of why it's not a good idea to try to put something in element 100 of an array that's only big enough for 10 elements ("element 100" overlaps with some other variable, or is outside the program's memory space entirely). The simplified model ignores some things, but I think it's enough to understand at least some of what's really happening, at least to the point where "HLL programmers have no idea" doesn't seem to me to quite apply.
Ok. I'll try to watch for different meanings. So far, I hadn't detected any. Note that there are many ways to "allocate" many flavors of space. I understood your use. I was...
I may be flogging a deceased equine here, though, or just confusing things further ....
Okay .... well, I think that's a little clearer.
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...
Can we snip out the cross-post? I don't think the crypts care about this flavor of stuff In our development world, it was often important to distinguish what code of the operating system...
"Never"? Hm, so the new toy will be a permanent snow-averter? Did you have to pay extra for that feature? :-)
And my "oh well" was about that precise scenario that didn't stick in your memory over the week or so it took me to find time to reply ....
-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.