User talk:NicM/Archive 1

From Wikipedia, the free encyclopedia

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Contents 1 Thanks for helping out with OpenNTPD 2 Barnstar for your help :) 3 Baptist Churches 4 horrible double-link 5 OpenBSD 6 Rob Martello 7 open-source 8 You are awesome 9 Better? 10 Axial Age 11 Open Letter to the editor NicM 12 yammering 13 The sincerest form of flattery 14 FreeBSD article (external links) 15 Culver Academies Talk Page 16 Buffer overflow 17 sizeof parentheses 18 Technical evangelist merged; please help 19 Template:FOSS celeb

Thanks for helping out with OpenNTPD

Hi NicM, thanks for cleaning up after the mess I made in OpenNTPD. I was working all night trying to bring OpenNTPD out of being a stub. I think I did fairly well in expanding the article (given the state that I was in), but you made it even better with the edits you committed :-) You reckon we can bring it out of the stub state as it is?

By the way, your username is very familiar... are you NicM from #OpenBSD @ freenode.net?

Atholas 00:58, 17 September 2006 (UTC)

I can't really think of much more to add to the article: what more is there to say about a small, young daemon that corrects the time? I wouldn't class it as a stub now though, I think it has enough content not to be. Yes, I am NicM from freenode #openbsd :-). NicM 09:10, 17 September 2006 (UTC).

Barnstar for your help :)

Graxe 03:08, 10 February 2006 (UTC)

Thanks! :-) NicM 08:17, 10 February 2006 (UTC).

Baptist Churches

NicM, I don't understand your removal of so much information on these pages, can you please explain. (From a learning point of view).dvc214 23:30, 17 December 2005 (UTC)

• Well, firstly I hope I haven't caused any offence. However, I don't think I really removed that much relevant information. Generally, I removed or rephrased:

1. anything that was not encylopedic or was irrelevent to the general reader (eg, phone numbers, addresses, details of who runs what and their photos);
2. anything that did not fit with a neutral point of view: talk about the friendliness of the congregation, while it may well may be true, is certainly subjective;
3. emotive words and phrases like "vision" and "God's church"—these do not maintain a NPOV, they have an advertisement tone that is not appropriate for an encylopedia;
4. duplication: much of the articles were duplicates of each other or had links that would be better in a more general article (eg, Baptist or similar), so I tried to keep each article focused only on its subject and leave the other topics to their respective articles.

I then simplified any remaining text so it got across the basic facts without cluttering up the article. For example, describing it as a "cluster", while perhaps accurate, is not a word many would associate with a group like this (it is an organization, yes? calling a spade a spade is always preferable :-). It also reads better to try to pare down the text into paragraphs of reasonable length rather than many short paragraphs of one sentence, and to express things simply rather than in fanciful language.

It's quite hard to express but generally it is a matter of being encyclopedic. I looked at the articles and extracted the information that I would expect to read about them in an encylopedia entry, and edited it to be neutral in tone. I don't mean to sound dismissive, but the organisation and churches and their leadership are not really notable enough to warrant a detailed individual listing with photographs. If the organisation or church was world-renowned, or the church buildings a particular fine example of architecture or the site of a momentous or interesting event, or a current or previous parishioner was famous (or infamous), perhaps it would be different, or at least that would be worth mentioning in the article. Otherwise, names and details are only worth mentioning as an aside (after all, how much would they mean to most readers? how many people know Chipping Campden well enough to know what "the square in the centre of the village" means? the few that would, they follow the link to the church's official website and find out all the details there, assuming they don't know already).

The only thing I can really see I omitted that may be worth reincluding is a few sentences on "The Vision", but it would need to be rephrased so it is NPOV. If it has led to any significant events (perhaps the opening of the new church is one), I'd say something like:

"The organization describes its goals as "to proclaim Jesus Christ to people today" and "to build God's church and to reach the nations"; so far, this has included the establishment of a new church in the local village of Bidford on Avon and something else."

Although you would probably need a reference for those quotes. Or, perhaps, just modify the text it a little:

"Established in 1999, Cornerstone Churches is an organisation of Baptist Churches in and around the Cotswolds in England. The Baptist faith places authority in the hands of local churches and encourages them to spread their beliefs and "reach the nations": this organisation was formed so its members may work together towards this goal. The churches also share leadership and resources and occasionally participate in joint events."

Anyway, it is pretty late so I hope I have made myself clear. Note that I haven't been editing on Wikipedia that long myself, so the above is solely my view; Wikipedia has many pages of policy and guidelines that you may want to browse to get information from the horse's mouth, and plenty of other articles if you want to get a feel for the style and tone (WP:FA has a list of what are seen as some of the best). NicM 02:02, 18 December 2005 (UTC).

Understood, I guess I was trying to be factual, but the information can be read from the external link. I'll bear your points in mind. Thanks dvc214 13:11, 18 December 2005 (UTC)

horrible double-link

I was, in fact, imitating the double-link in header of Template:Linux-distro where it says "Linux distributions" — you may want to change that one, too. --tyomitch 10:13, 15 November 2005 (UTC)

Good point, thanks. I didn't notice that one. NicM 10:22, 15 November 2005 (UTC).

OpenBSD

Wow. You have really done some incredible work on that article. Nicely done. -James Howard (talk/web) 12:36, 13 December 2005 (UTC)

Thanks :-). NicM 14:06, 13 December 2005 (UTC).

Rob Martello

Hi, you started this article and it's been nominated for deletion. The discussion is here:Wikipedia:Articles for deletion/Rob Martello. cheers, pfctdayelise 23:16, 18 December 2005 (UTC)

Not guilty. I nominated it for deletion but I didn't start it. NicM 08:28, 19 December 2005 (UTC).

open-source

Thanks for fixing up my open-source topics. Out of curiosity - how does everyone monitor this? Whenever I add an article, someone is on it right away, sometimes within minutes. Is there a new article list or something? Bhludzin 14:59, 6 January 2006 (UTC)

No problem. As far as finding your changes, well, this time, you added a link to an article I had on my watchlist (Operating system advocacy), so I looked at that article and it led me to the others. Even if you hadn't added a link, sometimes I check the contributions of people (eg Special:Contributions/NicM) who I notice editing pages I'm watching, in case it leads me anywhere interesting; I expect other people do this too. There is also the Recent Changes page: a lot of people monitor this. NicM 16:41, 6 January 2006 (UTC).

You are awesome

You are cool. I would give you a barnstar if I had the patience to figure out how to do so. But yeah, keep it up. Lotusduck 21:14, 18 January 2006 (UTC)

Thanks :-). NicM 21:24, 18 January 2006 (UTC).

Hey, you know, I just came by here to do the "you are awesome" thing, and found i had already done it once. Wow, good job. Lotusduck 02:04, 24 January 2006 (UTC)

Better?

http://en.wikipedia.org/wiki/Adrian_Lamo —Preceding unsigned comment added by Jagunde (talk • contribs)

Yes, much better, good job. I've made a few additional fixes. If you want to do more, it still needs more personal information and has way too many external links, some of which could be converted to proper references, I expect. NicM 08:47, 20 January 2006 (UTC).

Is there anything you think this article is missing? I mostly (try) to keep my edits within the realm of factual corrections, or additions of events or facts that make the picture presented clearer. If there's anything I can point you to in the way of information, please let me know; I don't like seeing my name appear too often in the edit history :)

Adrian Lamo · (talk) · (mail) · 18:53, 21 January 2006 (UTC)

I don't know, offhand I wouldn't say it requires a lot more content, it reads reasonably well now and the "homeless hacker" moniker and the arrest and are, without trying to belittle anything else you've done, probably the most notable things and they are both mentioned, it probably isn't appropriate to add too much unrelated content in there. The personal section could stand some expansion, perhaps a short bit on how you got interested in computers and ended up with the lifestyle described, and why you refused payment (and who offered to pay if there are sources), I don't think it's required though. It would be nice if at least 2/3 of those external links were removed or converted to use as inline references, I think the list is far too long for a relatively short article. I don't have time to make any changes beyond style fixes right now but I might have a go at some point if nobody else does. NicM 19:50, 21 January 2006 (UTC).

Axial Age

I have seen the pages you referred me to but still I do not understand your comment that my article is unintelligable. I take issue of the fact that you removed a substantial part of my article in october or november. I do not think that the purpose of Wikipedia is to dumb down the article. So, what is the exact nature of your complaint. Poldertijger Poldertijger 14:38, 28 January 2006 (UTC)

I am sorry you feel the article was dumbed down, but my changes in December (I made no changes before that) did not remove much content, merely reordered it to make it clearer and commented a list that did not have much context and was unnecessary detail given the rest of the article. I have never said it is unintelligible, merely confusing. The purpose of Wikipedia is to be an encylopedia, remember that the majority of readers will not have any background in philosophy.

The article doesn't read too badly as it is now, but there seems to be to be an awful lot of context missing. Part of the problem is that it is too long to be a summary and too short to really seem to explain the subject, so it seems quite confusing. A few points:

• What made Jaspers hit upon this theory that there was this same intensity of thought?
• What did he class as "intensity of thought" anyway?
• What happened in 800 BC to make him mark it as the start and 200 BC to mark it as the end?
• What did he mean "measure the quality of their thinking"? An example might help. Any particular future generations is he thinking of?
• He couldn't define a cause or connection, did he have any explanation at all?
• What is the context of this term: do any other philosophers agree with him? is it widely accepted or a fringe thing? was it part of Jasper's wider theories?
• The most prominent criticism is that this age is in fact only so far as we can remember, who says this? Is there any rebuttal?

The "Characteristics of the Axial Age" section needs to be expanded, at the moment it seems fairly ad hoc. It could do with an example covering each of the four characteristics ("This showed itself in X with the appearence of A, who said that B and made C happen."). This part (ie what he said the Axial Age is and why) should probably appear before the criticisms. I'd either expand the criticisms and make it a seperate subsection, or just include the characteristics section inline without a subheading. Hope this helps, in any case. NicM 15:06, 28 January 2006 (UTC).

Oh, also, "English-speaking theologians" like it... any particular reason? NicM 15:10, 28 January 2006 (UTC).

Open Letter to the editor NicM

My dear editor NicM,

I’m not opposed to the principle of editing. I understand that many of the entries in your Wikipedia have caused you a lot of grief. Far be it from me to be in the way of you doing your job in order to improve the Wikipedia; in the end I, an avid user of the encyclopedia, will benefit from your work. But I have a problem with the way you seem to see fit to do your job. In the particular case of the entry “Axial Age” you have put three tags that will effectively shy away people from reading the article. I don’t think this to be in the interest of Wikipedia. I will give an exposition of my arguments after explaining why I thought it necessary to write the entry “Axial Age”. In the books of Karin Armstrong this idea is mentioned a few times without an explanation being given. I tried to find the explanation on the internet, but there isn’t one. It is however remarkable that quite a few English speaking theologicians use the phrase “Axial Age”, so clearly there is a need for an entry in the Wikipedia. But when I tried to look it up I found a stub. Soon hereafter I came to find Jaspers’ vom Ursprung und Ziel der Geschichte in a second-hand bookshop. Now I got the information straight from the horse’s mouth. I found that Jaspers had been making a legitimate point and that’s why I set myself about to write the entry.

You have put three tags in the entry. My main complaint is that by doing so you are not solving any problem, if indeed there are some. I fear that by your attitude people will be dissuaded from committing themselves to the laborious job of improving the entry. The tags will be shown forever and people will just give up using the entry as a source of information. I ask you how we can get those tags removed. What do you mean that the article is in need of an expert? Jaspers certainly wasn’t an expert in the field of history but that didn’t refrain him from writing his book and coining the phrase “Axial Age”. This has proved to be to the advantage of theologicians, who can make use of the idea. Do you think I didn’t get the meaning of the idea “Axial Age” straight? Well, you didn’t exactly show yourself to be an expert when you edited the article and took away the item significance of the Axial Age. It may seem odd to you, but it was essential to Jaspers’ mind and should be part of any article concerning the phrase “Axial Age”. For all means and purposes I’m your expert on the item “Axial Age”; you have seen to that by putting the tags in the article and by doing so discouraging anybody to make a contribution. Don’t think that you will get help from theologicians; I’ve found that these people just don’t know the origin of the phrase “Axial Age”. To wit, the fact that they translated the phrase into “Axial Age” instead of “Pivotal Age”, wich they should have done. Or did someone made you believe that my article is flawed? Well, let him write a better entry, have him improve my entry, or, better yet, let me in on the secret. And let me make one more observation; the first person to write that the phrase “Axial Age” has been an inaccurate translation of the German word “Achsenzeit” can’t be totally out of his wits. I am, of course, referring to myself. Do you have a problem with the way I have put the article into words? Well, why did you make use of my phrases? Surely you can’t expect to improve the article that way. Then you have only yourselve to blame to have done a bad editing-job. Do you not understand some or most of the phrases that are used in the article? There may be a problem. Jaspers is using literary terms that shouldn’t be taken literally. Theologicians are used to this kind of language, but I can understand why this would pose a problem to others. If this is the sticking-point then this problem has to be remedied by explaining the phrases. Let me know and I wil set myself to improving the article. I can’t help pointing out that some readers have contributed to my article; they must have understood and thought it worthwhile their effort. The readers seem not to share your point of view.

You have altered my article to make it fit the standards of Wikipedia; I can live with that. You have callously removed an essential part of the information; I cannot let that stand. I don’t understand your problem with the significance of the Axial Age. It’s not a flame or a troll, so why remove what is an essential piece of information? Do not refer to the manuals again; they cover too wide a field to be of any use regarding the nature of your problem. Be specific: I’m not averse of improving myself but I don’t like to stumble in the dark. I’ve seen your personal page so I know that you are capable of giving this kind of information. You have set yourself to be an editor of Wikipedia; then act like one. There is more to the job of editor than just butchering a badly written article.

Frankly I don’t like the way you have treated me thus far. For the moment I’m willing to give you the benefit of the doubt. I suggest that we get over the bad start of our relationship. I’m willing to make the effort. I hope you can do the same.

Poldertijger 10:53, 30 January 2006 (UTC)

ps I've written my letter before I had the chance to see your advice. My questions have been answered and fully answered, by the look of it. I will certainly try to improve my article with the help of your advice.

Poldertijger 10:53, 30 January 2006 (UTC)

I was just writing a reply to you anyway. I think you may slightly overestimate the importance and underestimate the usefulness of these tags: they are not intended to be accusatory, merely to mark that an article could do with improvement. Most of the editors (aside from yourself) on this article have not made significant changes, perhaps this is because they approve, as you seem to imply, or perhaps it is because they do not feel expert enough in the subject or do not have the time—the aim of the tags is to add to articles which it seems could require improvement and to attract additional editors who are experts or do have time and hopefully get more views, opinions and improvement (otherwise you are relying on them just happening upon it). Sometimes this doesn't work, and even then, maybe they will make any readers who find it look over it a little more closely, and perhaps try to improve it, which I think is also a good thing.

Theologians may use specific language, but Wikipedia is not a theological textbook, it is an encylopedia, so it is important to express (where possible) ideas in language that is accessible to the general reader. By all means use theological terms, but often it is worth checking if they are defined elsewhere on Wikipedia (one of the Theology articles perhaps, or would it be appropriate to create a stub article defining the term) or if a quick sentence defining it would be appropriate. Although, in any case, as you will have seen from my comments above, my main problem is not so much now the language, but the fact that the term is not really placed in context.

I am sorry you are offended that I removed the section, but I think that as it stands it does not add anything more to the article than is explained before it and am of the mind that such content should be removed (as I said above, if phrased with or as an example it would enhance the previous definition of the term, rather than just seeming a little out of context). Note that I didn't remove it entirely, merely commented it, hoping that some future editor would spot it and expand it.

Anyway, I'm glad that you think my original comments are useful and are intending to improve the article. NicM 11:18, 30 January 2006 (UTC).

yammering

I've said something on the talk page for OpenBSD, figured I'd make sure you knew it. 65.94.60.22 23:01, 16 March 2006 (UTC)

The sincerest form of flattery

Hey, NicM: I see you're primary author of OpenBSD security features; I thought you'd like to know that none other than Theo de Raadt has mentioned your article approvingly. See this interview with him: http://os.newsforge.com/os/06/03/20/2050223.shtml. --maru (talk) contribs 18:10, 29 March 2006 (UTC)

Heh, great! Thanks for letting me know. NicM 19:37, 29 March 2006 (UTC).

FreeBSD article (external links)

Any particular reason you yanked http://www.freebsdwiki.net? Admittedly, as that wiki's proprietor I could be considered less than neutral on the topic, but I think it's pretty relevant and worthwhile regardless. --Jrssystemsnet 19:17, 6 April 2006 (UTC)

WP:NOT a links repository or indiscriminate collection of information. Is that site about FreeBSD? Sure, but so are hundreds of sites. Is it produced by the FreeBSD project, or say something unique and informative about FreeBSD for an encyclopedia reader? No, it is a collection of tips, howtos and instructions for FreeBSD users. Is it a landmark in the FreeBSD community or significant to the FreeBSD article in some other way? That is harder to say, but I don't believe so. I am not trying to denigrate your work in any way, but as useful as your site may be to FreeBSD admins, I do not believe the Wikipedia FreeBSD article is the place for advertising it. I can find hundreds of FreeBSD tips and howtos on the internet, what makes your site any more significant than them? You aren't even near the top of google for most obvious searches. NicM 07:51, 7 April 2006 (UTC).

That said, this is not a massive issue for me. I just think that if anyone tries to add any more sites like this, they should all be removed (including yours) rather than accepting an endlessly growing list of vaguely relevent sites. External links have a tendancy to fill up with all sorts of useless stuff as everyone adds their favourite site. NicM 07:59, 7 April 2006 (UTC).

Culver Academies Talk Page

NicM, I really appreciate the help you gave me on the Talk:Culver_Academies page. Not that I am an expert now but I was certainly a beginner when we had that discussion and it helped me learn. I think that it might be a good idea to remove/move that conversation so that more (or still) relevant discussions can take place. I also think that it would be good to highlight some of the pertinent information that we got from that talk, such as the list of "four substantial sections" needed. etc. Andrew Powell 18:31, 26 April 2006 (UTC)

Archiving talk pages is fairly easy, see Wikipedia:How to archive a talk page. If you want to put a summary of pertinant information from archived discussions on the page after you have archived them, nobody will mind :-). NicM 18:46, 26 April 2006 (UTC).

Buffer overflow

Hello Nic, thankyou for removing my "mess of changes". Personally, I thought the earlier version was a mess and I made a valiant effort to tidy it up. It was biased strongly towards deliberate use of buffer overflow throughout the article without fully explaining beforehand the actual varieties and consequences of each one.

I worked for 30 years with buffer overflow problems in the real world and solved thousands of examples of it by creating a simulator that detected all of the ones I could.

I re-organised the article to split Buffer overflow (accidental) from buffer overflow (deliberate) and its implications for computer security. I gave a nice simple example of a straighforward overflow using a single instruction.

I also widened it considerable to include buffers in general rather than specifically stacks, file buffers amd the like.

I also introduced some historical perspective taking it away from examples in PC world to simple example from early programming.

I think if you review it further you will see it is far more logical the way I had it.

I thought I would improve the appearance and ease of grasping the various examples given regarding return address corruption etc but didn't have time today.

I am not too happy that you decided to effectively revert the entire re-structure without giving valid reasons.

There is now no longer any discussion of how it is theoretically possible to detect 100% of buffer overflows for any language including ones with pointers. There have been a number of very successful products that have sold precisely because of that capability including my own.

by the way. I only just discovered the "+ to add a topic!

Comment? —Preceding unsigned comment added by Kdakin (talk • contribs)

I wasn't implying that the general thrust of the changes were inappropriate or incorrect, or impugning your experience. However, you succeeded in introducing a large number of errors: removing capitalisation from some sentences, adding some red (broken) links, and adding spelling mistakes or typos. Also, I strongly disagree that moving straight from your too brief definition into a set of examples is more logical, or that it is more logical to throw the reader straight into obsolete (assembly!) source code rather than walking through some examples in text and diagrams before reaching code. If anything, obsolete, niche examples in low-level languages deserve to appear at the end, if at all. Remember that the article is intended to educate the general reader, not just experienced computer programmers (who probably already know what a buffer overflow looks like).

Perhaps for a start it would be best if you were less ambitious in each change: be a little more careful about spelling, grammar, and style, and limit your changes more: perhaps rewrite or move only a single paragraph at a time so it is easier for others to proofread your work? Or for major changes, present a plan of what you intend to do and how you intend the article to be laid out on the talk page and allow others to discuss it. Also, it is important to include references with your work, particularly new sections that are less well known (such as your new content on monitoring programs). Yes, I know that much of the article as it stands is poorly referenced, but that is not an excuse to continue in the same vein. NicM 17:51, 12 September 2006 (UTC).

I don't know what planet you are living on - but Assembly language is anything but obsolete! (Neither are mainframes, they have just been renamed "Servers" - there is not much new under the sun! It is actually just marketing and re-discovery of old truths with new names dressed up as new products).

It is clear to me that experienced programmers do NOT know what a buffer overflow is and even people who do seem unable to give a simple and clear example of one without recourse to thinking that the solution is a simple matter of choosing the right language or compiler or that "exec time checking" isn't sometimes potentially costly in performance. Where was there a single mention of (bad) pointers in the original article? or the run-time overhead involved? or hardware channel overflows? or inappropriate use of static variables in a multiprogramming environment?

I was not aware that red links were "broken" links - forgive me but I quite genuinely thought they were simply "not yet defined" am I wrong? There seeem to me to be very many well known expressions that are simply undefined at present on wikipedia.

As for my "New" content on monitoring programs, they have been around for 30 years and more - what is peculiar is that you think it is new! (I admit that you obviously believe it is new, perhaps because it wasn't even mentioned in the prolific set of examples that were cited without a single reference to the one and only technique that can catch them all!)

Being "less ambitious" on an edit is half-hearted at best when the article was/is so repetitive, clogged up with examples of deliberate buffer overlow examples without properly explaining various classes of the problem.

I am perfectly happy for the extremely simple example of IBM S/360 Assembler to be replaced by an equally simple example from current languages if you can think of one that illustrates it quite so simply in as few lines that also provide helpful comments on the same lines as the code.

I think any programmer would understand the basics from the example given even if they were not an Assembler programmer.I have to admit I did genuinely consider giving an example of a bucket of water and a literal "overflowing" of H2O but the analogy wasn't quite fitting enough for computer programming.I will keep working on that concept however.

As for the general reader, the examples given on original article were/are not clear at all, which is part of the reason I decided to have a go at improving it. Sadly, I ran out of time today to do much more but I have previously been halfway through editing on previous occasions, been locked out of my PC through unexplained system crashes (buffer overflows?) and thought I better save it and go to the pub before it was all lost!

As for introducing a "large number of errors", I dispute that. Maybe with my urgent desire to save the re-structured text, I was a little rash without checking 100% for typos and capitalization before saving today. I am indeed humbled that you should detect the odd spelling, punctuation or other small error. But the punishment does not fit the crime. Would it not be more appropriate to look to see what I left in (actually most of it for now - but I did delete the repetitive stuff and introductory "disambiguation" when it wasn't strictly necessary) or simply moved the order around a bit to make it more logical and less rambling.

Please explain the (serious?) errors for my enlightenment?

Also can you point me in the direction of how I can draw diagrams easily on wilipedia?

As a complete aside, I have noticed that the "search" on Wikipedia [for a pre existing article] is extremely case sesitive and frequently doesn't find any reference to an existing article even if actually present - is there some problem with it at the moment?

I do think wikipedia is the best thing since sliced bread but dont kill the geese!! ken 23:42, 12 September 2006 (UTC)

I didn't say assembly language was obsolete, I am an assembly language programmer, however, the assembly language example you chose was niche and obsolete. If you must use examples in assembly language, either use something very simple, or use something very common, such as i386 or ARM. However, I would strongly disagree with using assembly language for primary examples at all: use a common, simple high-level language like C, BASIC or (if you must) Pascal. In any case, comment it copiously: most readers are not programmers and even if they are, you want them to find the article easy to understand, right? I mean, let's take a look at your code:

• What does the "AP" instruction do? What does the "=1" part mean? Ditto "=CL" on "MVC"?
• What do you mean "embedded field"?
• What are the "HERE", "THERE" labels for? They are labels, yes? They look like they aren't used, correct?
• What is all this "* ." stuff?
• What is the difference between "DS", "DC" and "EQU"? What does "EQU *" mean?

Some of this may be mentioned in the text, but if so, I am missing it. I will give you the benefit of the doubt in your errors being due to rashness. Anyway, the problems with your version as I see it:

• You removed a lot of text from the lead-in and generally made it much worse. It is irrelevent whether buffers are static or dynamic (buffer overflows are the same principle regardless) but the previous definition of what it does and what it is is very relevent. There was also some horrible talking-to-the-reader "see below" stuff which is pretty unhelpful.
• The text then walked straight into a poorly described assembly example which is hard to follow, particularly as the first paragraph now barely describes what a buffer overflow is.
• I don't think you should talk about what are primarily exploit mitigation techniques before talking about exploits.
• Your new text is generally far too sketchy and makes too many assumptions that the reader is technically inclined. Particularly the three before the "basic example" section, although I will accept you may not have finished them, but also other sections.
• I generally noticed lots of little mistakes, although looking back not quite so many as I first thought.

Red links do mean not defined. However, very often if something is not defined the way you think, your terminology is incorrect, or the term is not worth defining with an article all of its one. Generally, think carefully about what you could point it to before either leaving red links or creating lots of new articles. Diagrams, well, look at the source to see how the current article does the box ones, otherwise it is probably a case of drawing images, uploading them and including them in the article. I don't know about problems with the search, maybe there are some at the moment (the Wikipedia software sometimes does seem to have lots of problems).

Monitoring programs may well have been around for 30 years or more, but I haven't had experience with them, and your content gave me no references or citations with which to improve my knowledge so I could check over your text.

Some of your ideas, however, are good. I see the article requiring the following sections:

• A proper lead-in: this should define the subject and touch on most of the points expanded on in the article.
• Technical details: what a buffer overflow is, how it occurs, and some talk of its consequences including a very well commented example in a high-level programming language. This should be mostly text and very little code. I would seriously try to avoid filling the article up with tons of examples in other languages, it wouldn't help anyone. And I would avoid assembly, particularly old, "legacy" and little-known assembly.
• Perhaps a computer programming section: covering common programming (rather than security) problems with buffer overflows and some non-technical discussion of how they are avoided. This may have a lot of overlap with the security section though: generally buffer overflows are both a security and programming problem. I can't really think of enough content to go into this that doesn't overlap. Any suggestions?
• Computer security: this would cover buffer overflows specifically in computer security, history, exploitation, objectives, mitigation.
• More images and to avoid becoming too long :-)

What do you think? If we can agree a set of sections, we can reorganise it, I don't disagree that the article could be much better. Let me know your suggestions for sections and I'll comment. In general, long paragraphs, few sections, text rather than code and lists, non-technical descriptions, are to be preferred. Even the present article is far too technical. I'm not going to suggest making it so that my Dad (computer beginner) could understand it, but it should be understandable by my boss (Visual Basic programmer). Take a look at WP:FA if you want to see examples of good articles. NicM 07:42, 13 September 2006 (UTC).

I strongly disagree with many of your comments. I think your arguments are defensive rather than logical or constructive.

I will try to answer each and every one of your points as you have raised them. I am very open to constructive criticism but it seems to me that you are in denial - your lack of knowledge of Assembler is obvious from your comments. My comments and labels were patently "self evident" and self documenting. Even if you don't fully understand the actual instructions, the context was clearly self evident. How can a high level language example be "simpler" than a one instruction machine code example ? (even if so called legacy code). A more complete answer will follow soon.

I challenged you to provide a simpler example but you were unable to provide one - doesn't this speak for itself? You even admitted that you were not familiar with this particular method to prevent buffer overflow - this in itself demonstrates a lack of appreciation for a solution that (in essence) is only 13 machine instructions long!

You criticize my re-structuring that actually does what you claim is lacking! It will probably take me several hours to fully answer your comments adequately - I am sorry but it will take a day or two to respond - meanwhile I hope others may comment on my behalf in support of what I am claiming. —Preceding unsigned comment added by 84.13.62.126 (talk • contribs)

I have considerable experience writing code in ARM assembly and various 8-bit assembly languages - if you manage to believe otherwise from my comments you are less perceptive than you think - and also writing technical documents and instructions for non-technical people to follow and supporting them while they do so. If you really think your comments and labels were self-evident, you are, I'm afraid, painfully deluded.

You are also misreading my comments, I pointed out only that I am unfamiliar with the method of locating buffer overflows using emulation or monitoring as your new content describes not that I am unfamiliar with buffer overflows themselves. Nor did I say I didn't understand your code, I merely asked some questions the general reader of programmer unfamiliar with assembly language would be likely to ask about it. There is an example of a buffer overflow in C in the article already, although I admit it is far from perfect, although even it is more readable than your example. I have offered quite willingly to help you to improve the article and integrate your suggestions but your refusal to understand that not everyone is an experienced assembly programmer - or even an experienced programmer in any language - seems to be rapidly turning this into a waste of time. NicM 22:28, 13 September 2006 (UTC).

BTW, I'm not saying your example isn't simple - you obviously can't get much simpler than one instruction - I am saying it isn't clear or understandable to most readers and that, in general, high-level languages use fewer abbreviations, arcane symbols and unclear syntax that the average reader will find hard to decipher without explanation - which your example does not provide. NicM 00:10, 14 September 2006 (UTC).

The reason my initial suggestions are close to yours is because, as I said, I think some of your ideas are good. I think splitting it into a technical/programming/security form (if there is enough content for the programming section, which I am not convinced of) is a good idea. However, your changes to the lead-in were awful, I feel your examples and technical section were poorly explained and hard to understand (as I have said previously), some of the movement of text was questionable and that generally your edits made the text more technical and harder for the general reader. Perhaps if you were to expand on your ideas here and present your rationale, we can reach a compromise that improves the article. NicM 00:22, 14 September 2006 (UTC).

Okay, if anything in the above text seems insulting (although I think I've edited it to get rid of that ;-), I apologise, I was a bit annoyed. Anyway, being constructive rather than getting annoyed, how about this example of a buffer overflow:

#include <string.h> /* This includes the definitions of the C string library, so the strcpy function may be used. */

/* This example defines a standard C main function to demonstrate a buffer overflow. */
int
main(void)
{
    /* The example really starts here. */
    char buffer[10]; /* Declare a buffer of 10 bytes (C's char type is 1 byte). */

    /* This statement uses the standard strcpy function to copy a string into the buffer. Since the
       string is longer than the 10 characters reserved for the buffer, and the strcpy function does
       not perform any bounds-checking, characters are written after the end of the buffer - a buffer
       overflow. */
    strcpy(buffer, "This string is much longer than 10 characters!");

    /** More code would appear here. **/

    /* This is the end of the program. */
    return (0);
}

It may be better to do something with a for or while loop so it is clear it is going beyond the end of the buffer, although that is even more contrived than the example above. Or we could think of something in assembly. Hmm. ARM assembly is RISC so it is a poor choice, but even so:

; This code demonstrates a buffer overflow caused by an off-by-one error in ARM assembly.
.Source_String                 ; These two lines declare a 12-character string in memory at the label
    equs     "0123456789AB"    ; Source_String. This is the string the code is going to copy from.

.Target_String                 ; This is the target string (buffer) the code is going to copy to.
    equs     "ABCDEFGHIJKL"  
 
.More_Data                     ; This is some unrelated data after the target string which will be 
    equd     1,2,3,4           ; overwritten by the buffer overflow.

.Start                         ; This label marks the start of the example code.
    
    adr      r1,Source_String  ; Load the address of the source string into the r1 register.
    adr      r2,Target_String  ; Load the address of the target string into the r2 register.

    add      r3,r1,#12         ; Put the address after the last character in the source string into r3. This is used to find out
                               ; when we have reached the end of the string.

.Loop                          ; This label marks the start of the copying loop.
    ldr      r0,[r1],#1        ; This loads the byte at the address in r1 into r0 and makes use of the instruction's post-increment
                               ; feature (the last #1 component of the instruction) to automatically add one to the address in r1
                               ; after the data is loaded into r0.
    str      r0,[r2],#1        ; This is similar, but stores the data at the address in r2 before incrementing it.

    cmp      r1,r3             ; This instruction compares the address of the current character in the source string with the 
                               ; address of the last character and sets processor flags depending on the result.
    ble      Loop              ; This returns to the Loop label to copy the next character, unless the current character's
                               ; address is before or at the end of the string. This is the cause of the buffer overflow, as the loop
                               ; will be executed when the loop counter is at the end as well as before the end it copies a
                               ; total of 13 characters rather than 12. The programmer should have used the "lt" suffix                                 
                               ; to make the loop continue only until the last character. Because of this the first byte at the
                               ; More_Data address is overwritten - this may cause problems if later code expects it to still hold
                               ; a 1.

Although this is a bit contrived (you wouldn't copy stuff this way), and a lot less understandable than the C. NicM 22:48, 13 September 2006 (UTC)

Hrm, we could probably even make your example better, although I don't know the syntax so forgive me if there are any errors.

; This instruction copies the 28-byte string "THIS IS A VERY LONG STRING!!" into a buffer (declared later at the BUFFER label) which is only 
; 20 bytes long. It will succeed, as the programmer has explicitly declared in the instruction that 28 bytes should be copied.
      MVC     BUFFER(28),=CL28"THIS IS A VERY LONG STRING!!"

; *** Execution continues and many other instructions may be executed here. ***

; Now the code tries to make use of (increment) the contents of the address at MOREDATA. However, the previous MVC instruction wrote 28 
; bytes rather than 20, so the data has been overwritten and this instruction is likely to do the wrong thing and cause the program
; to fail.
      AP      MOREDATA,=P'1'

; These are the declarations of the buffer and the data following it. The buffer is declared as being 20 space characters.
BUFFER     DS      CL20' '
MOREDATA   DC      PL6'0'          ; The first eight bytes of this data will be overwritten.

; This marks the end of the source file.
      END                

NicM 23:37, 13 September 2006 (UTC).

Looking at it, a better commented version of your example has the advantage of being short, which - with proper comments to explain what is being done - probably mitigates any disadvantages of it being much less well-known than C, so it would probably do. We could probably think up examples in almost any language without bounds-checking but in the end it comes down to whether or not it can be made understandable to those who are not familiar with the language (or even not that familiar with computers, although that may be asking a lot for this subject). A better one may be i386 assembly which is both CISC so it will be compact and well-known, but I am not familiar enough with it to write an example without some research and it is too late in the evening for that now. NicM 23:48, 13 September 2006 (UTC).

Although, looking at it again, it has some disadvantages of my C version too... a "magic" function (strcpy/MVC) is used which "magically" makes a buffer overflow happen, it may be better to use an even more contrived example which actually shows the good bytes and the bad bytes being written. With that, it would be possible to use a state table to show what was happening to the target buffer after each iteration. Suitable code and a state diagram could form the centerpiece of a very good technical explanation. NicM 00:50, 14 September 2006 (UTC).

Pseudo-code might be better for that than real code. NicM 00:53, 14 September 2006 (UTC).

ken 13:54, 14 September 2006 (UTC) I will answer your last point first:

• I'm going to reply to this comment inline using bullet points since it is quite long. NicM 17:19, 14 September 2006 (UTC).

"Pseudo code might be better"

This was my first thought but after originaly considering it decided in reality that it would probably lengthen the example considerably by having to explain the pseudo code too!

• Length is not a problem if it improves the clarity of the example. It is more important to explain it in a way that is easily understood than worry about getting the smallest example or about the word count. NicM 17:19, 14 September 2006 (UTC).

Let us make an attempt just to see how it pans out making no assumptions whatsoever about the general readers knowledge about computer programming or languages (including how a comment is shown) other than the fairly well known fact that computers

• a) have memory and
• b) use instructions that alter the memory in some way and also perform calculations!

pseudo code example of buffer overflow.

Note: comments in the "pseudo code" start with a "/*" and end with a "*/" (all other notes are therefore shown this way).
/* "pseudo code" does not represent a particular type of computer programming 
/* - instead, it sets out the sequence of actions the computer takes using an english like description */
/* - in the following example the computer command  
/*     "ALLOCATE" means "reserve space for" from the available memory /* each character such as an "A", occupies one byte */ 
/*     "MOVE" actually means "take a copy of" or duplicate (Move has become commonplace (through long term usage) to mean copy! */
/*     this means the characters stay where they originally were but an exact copy is made at the "moved to" memory location.
/*     the characters may actually be "moved" or copied one at a time */
/*  */
ALLOCATE a CONTIGUOUS set of bytes from memory to contain 20 characters and give the string of characters a label "BUFFER". 
/* all further references to this set will be by the name "BUFFER" (without quotes) */
ALLOCATE a contiguous set of bytes from memory to contain 11 numeric digits and a sign and give the string of characters a label "VALUE". 
/* for this example we will assume that VALUE immediately follows BUFFER in the Memory */
/* (just like LIGHT follows DAY in DAYLIGHT with no gaps) */
/* - all further references to this second set will be by the name VALUE */
/* the maximum permitted numeric value in VALUE is therefore, +99,999,999,999 */
/* the number of bytes required to hold the number will vary from computer to computer - we assume 8 for this example */
MOVE "THIS IS A VERY LONG SENTENCE" to BUFFER    /* This causes the computer to copy these 28 letters across to BUFFER /*
/* unfortunately, this particular computer hardware is not equipped with a method of stopping after 20 characters */
/* and proceeds to "overflow" into the next reserved memory location VALUE , completely destroying the contents */
/* the next instruction shown below will either fail completely or give erroneous results */
"ADD" "1" to the number contained in VALUE.   /* this operation may fail */
/* the instruction ADD may be executed much later in the set of program instructions */
/* and so the location of the destroying instruction may be hard to determine in a large program */

• This is okay, although when I was talking about pseudo-code I was meant including a byte-wise copy so the user could see the exact point the buffer overflow occurred - with a nice state diagram this could be very clear. It would also be better not to wikilink things like allocate and move, explain them simply in the text, eg something like "this line allocates (reserves space in memory for) a buffer of 10 bytes". I'd also try to add more blank lines to space things out a bit and make it more readable. It would also be better to use complete sentences and paragraphs for the longer comments, or at least multiline comments. There are many pseudo-code styles, but I would probably have made something like:

; This is pseudo code of a simple buffer overflow.
buffer := array[10]                ; allocate (reserve space in memory for) a buffer of 10 characters in size

string := "VERY LONG STRING"       ; create a variable holding the string to copy from
length := 16                       ; assign the length of the string (16) to a variable
position := 0                      ; initialise a variable called position with the current index into the string

while position < length do         ; repeat this loop until the position variable reaches the total length of the buffer
     character := string[position] ; copy the character at the current position into a temporary variable, character
     buffer[position] = string     ; write the character into the right place in the buffer
     position := position + 1      ; increment position to move on to the next character
end

Obviously this could do with a bit more explanation, but it would lend itself well to a state table of buffer,length,position. NicM 17:21, 14 September 2006 (UTC).

I have put in links for Allocate and Move but you will observe that Allocate does not have a definition yet and Move has no disambiguation or computer science definition which is quite surprising as it is probably the most used computer operation in the commercial world of COBOL programming! Of course I could have defined them myself but this would be pointless if my section requiring it/them were removed as being no good.

• Dynamic memory allocation or static memory allocation perhaps. I'm not convinced comp-sci move requires a page of its own, copying bytes from one address to another is pretty easy to explain. NicM 17:19, 14 September 2006 (UTC).

"Legacy code unsuitable for example"

If the article had been about evolution and, after an initial technical description ,I had started with a discussion of genes and amino acids rather than say Erasmus Darwin or Charles Darwin I think I could be validly criticized for "jumping the gun" or starting rather too late in the story. Since the problem of buffer overflow has been around since "early" days of computing, it is fitting in my opinion to cite a simple example from this time. No simpler example can be found than a single instruction example.

• Although the history of buffer overflows is interesting and relevent and should appear somewhere in the article, it does not follow that we must use the earliest possible example to explain a concept that has changed little up to today and may be demonstrated with greater clarity and relevence using modern example. NicM 17:19, 14 September 2006 (UTC).

If we exclude bounds checking code inserted by the compiler or later languages which avoid use of pointers, we are left with either a machine code example or an Assembler code example. If I re-work my example down to its absolute minimum we have the following.

• Not true. C/C++ is probably the most common language in which buffer overflows are found in modern programming. NicM 17:19, 14 September 2006 (UTC).

* this is a comment line (starts with an asterisk)
* Move is the start of the program and its entry point. 
* -    MVC is an Assembler instruction meaning "move characters"  - actually "copy" a character string!
* -    DC is "define a constant"      - actually a variable with an initial value in this example of blanks
* -       and PL6 defines a numeric (packed decimal) constant of length 6 bytes, initial value = zero.
* the next two lines define two static variables that are contiguous in memory 
NAME   DC      CL20' '         this is an embedded (in the program) field of fixed length 20 bytes
VALUE  DC      PL6'0'          the first 4 bytes of this 6 byte variable will get overwritten by the MVC instruction "overflowing"
*                                                                                                              from previous field.
MOVE   MVC     NAME(24),=CL24"THIS IS A VERY LONG NAME"   this instruction will work fine, but the next may fail
       AP      VALUE,=P'1'     this instruction attempts to add 1 to the numeric number already in VALUE - but may fail
*
* the cause of the failure is that the Assembler length checker was over-ridden by the programmer deliberately giving a length
* of 24. If the Assembler had been allowed to choose the length, the error would have been detected at execution by the truncation 
* of the correct string ("NAME" would not be present on the output string) 
      END

• This is pretty good. I would add a but more whitespace, wikilink entry point, and copyedit the capitalisation and punctuation of the comments. NicM 17:19, 14 September 2006 (UTC).

"higher level languages use "fewer abbreviations, arcane symbols and unclear syntax" 

and

"obsolete, niche examples in low-level languages deserve to appear at the end, if at all"

In my opinion, MOVE or MVC is a lot more obviously associated with characters "moving" than the "strcpy" function in your "C" example. Your "improved" version of my assembler example is closer to what is probably required but my example actually attempted to demonstrate a number of other points simultaneously by my deliberate use of what you termed "unecessary" labels "HERE" and "THERE". They were only inserted to highlight the discontinuity in sequence (and time of detection) from the original cause of the error and its consequences.

• Well, except that it doesn't "move", it "copies", and most people will not know that in computing, "move" means "copy". Move seems perfectly obvious to you in the same way strcpy seems perfectly obvious to me because we are used to them, in reality are both pretty unclear. The only point in favour of strcpy is that more people know C, so it will be familiar to more people. I did not term your labels unnecessary, I pointed out that they only appeared once and so their use was not clear. NicM 17:19, 14 September 2006 (UTC).

As for IBM S/360 Assembler being either obsolete or niche I think not! I can do no better than refer you to the WIKIPEDIA article on System/360. Most of the worlds business still depends on this architecture in one way or another.

• Is that the same article that says "only a few System/360 computers are known to exist today in working condition"? They are no longer produced - obsolete - and exist in small numbers compared with modern hardware - niche. Sure, there are still a few out there, but looking through the job pages the ratio of S/360 asm to Java/C#/C++/etc programming jobs I see is less than 1:100. NicM 17:19, 14 September 2006 (UTC).

• ken 08:13, 15 September 2006 (UTC) I think you are under the mistaken impression that because IBM now market their hardware under different names it has somehow caused all those hundreds of thousands (millions even?) of "old" programs produced over decades to become obsolete! The dynosaur is still with us and it is an "enterprise transaction server" or suchlike.

Mainframes have always existed in small numbers (and especially so with everyone and his dog now owning a PC). The IBM S/360 is effectively "alive and well" as this extract from the linked article says:-

Later compatible IBM systems include the 3090, the System/390 family, and most recently (and currently) the System z9 and zSeries.

What do you think it is that keeps printing all those Readers Digest personalized letters (a Dell laptop?)!

• • Even so, it is a niche product. The niche may be large and expensive, but it is niche. The number of these boxes is dwarfed by the number of, eg, i386s, and the number of S/360 programmers dwarfed by the number of, eg, Java programmers. NicM 15:45, 15 September 2006 (UTC).

I did contemplate explanations of the "EQU *" for the labels but due to shortage of time thought I would improve it later. Incidentally, the use of "EQU *" rather than putting labels directly on the instructions serves to demonstrate good assembly practise where insertion of additional instructions can be achieved without removing a label from one instruction and adding it back to another which may introduce new errors to a program. In fact better practise still was to use "LABELXX DS 0H" which ensures the next instruction was aligned on a half-word boundary but I thought that was going too far.

• I think good practice should be used but it should not be used at the expense of clarity, nor should the example go off the track into explaining good practice, in the same way it shouldn't have to go off into long explanations of syntax :-). NicM 17:19, 14 September 2006 (UTC).

"If you really think your comments and labels were self-evident, you are, I'm afraid, painfully deluded."

HERE seems pretty self evident to me - its certainly not the same as THERE! don't you agree ?

THERE seems pretty self evidently different to HERE!

• Sure, they are different frome each other, that much is self-evident. But what do they mean? What are they used for? That much is not self-evident. NicM 17:19, 14 September 2006 (UTC).

NAME seems pretty self evident for a variable to contain the name of something (an implied character string) !

• This one is not too bad, although something even more obvious (without implications :-) like "STRING" or "A_STRING" would be better. NicM 17:19, 14 September 2006 (UTC).

VALUE seems a lot more self evident for a variable containing a numeric value than "MOREDATA"! (true but obtuse)

• VALUE is ambiguous (I know and you know "value" conventionally means a number, most people think of a price) and the fact it is numeric is irrelevent. If you wanted to specify it was numeric, use "NUMBER" or "A_NUMBER" but in this case it doesn't matter. "MOREDATA" is not perfect, but I couldn't think of anything else offhand. NicM 17:19, 14 September 2006 (UTC).

END seems pretty self evident to me (perhaps a little too obvious and therefore uneccessary even!)

• It is certainly unnecessary. You haven't mentioned your comments, which were also far from self-evident. For example... "Control is passed to this point sometime later"... control? what control? later than what? But you have given some much better comments for the example above so I will not continue to argue about this. NicM 17:19, 14 September 2006 (UTC).

"it may be better to use an even more contrived example"

Once again, I considered a byte by byte example but because of its greater complexity, plumped for the single instruction one. Yes, it would demonstrate the exact point of overwrite rather than the the mid-stream error and its postmortem but that's just a tad esoteric and probably better illustrated with a another pointer based example from say PL/1 or similar.

• Yes, it is more complex, but in some ways it demonstrates the subject in a clearer way. Rather than saying to the reader "this is a magic black box that we call and it causes a buffer overflow", we show in a step-by-step fashion exactly what the code/hardware is doing, ie copying too many characters and overwriting data. NicM 17:19, 14 September 2006 (UTC).

"your changes to the lead-in were awful"

Your lead-in started with a "Technical description" that appears to be a disambiguation for no clear reason, a programming error and a synonym all rolled into one. I quote:-

"In computer security and programming, a buffer overflow, or buffer overrun, is a programming error"

Your several computer security examples clearly demonstrate that it is not always a programming "error" yet you say it is at the outset and effectively contradict yourself later - that's not too logical or consistent!

• They are not mine, I didn't write the article and I have repeatedly said it is not perfect. In any case, buffer overflows always stem from a programming error, either directly or through lack of bounds checking (or compiler error, etc, in any case, they don't just magic themselves into existence, there is an error somewhere). You are correct that there is a potential for confusion, the article uses the term "buffer overflow" both for the act of overflowing the buffer and for the programming error (the potential buffer overflow) that permits it to happen. This is a question of semantics - the article should probably be changed to consistently use "buffer overflow" to mean the act of overflowing the buffer and use something else to mean the program bug. It should also be fixed without removing the initial part of the sentence, with proper grammar. NicM 17:19, 14 September 2006 (UTC).

"A buffer overflow is an anomalous condition where a process attempts to store data beyond the boundaries of a fixed length buffer.
The result is that the extra data overwrites adjacent memory locations. 
The overwritten data may include other buffers, variables and program flow data."

You then repeat almost exactly the same description as a "Technical description"

"A buffer overflow occurs when data written to a buffer, due to insufficient bounds checking, corrupts data values 
in memory addresses adjacent to the allocated buffer. 
Most commonly this occurs when copying strings of characters from one buffer to another."

If the introduction is not itself a "technical description" what's its purpose? It certainly seemed to be offering the same description as "technical description" to me but "mixed up", as I said, with uneccessary disambiguation and synonym. It also offers what is in effect a too simplistic (and singular) cause - "due to insufficient bounds checking" which ought logically to come later and discussed in relation to 'Prevention in a seperate section and related to choice of languages and to also include performance issues (as I had attempted).

• Please take a look at WP:LEAD. The lead-in is intended to define the subject and touch on most of the salient points of the article, so it can be perfectly alright that the definition of the term should appear in both sections in some form. You'll note that some of the content you removed from the lead-in was an attempt to do this, although the existing lead-in is far too short. NicM 17:19, 14 September 2006 (UTC).

Your heading line "Basic example" is misleading for the simple reason that "BASIC" is a programming language in its own right as I am sure you know and as such should be considered a "reserved word" that should only be used in descriptions when referring to the language itself. It should be avoided so that it is not at all ambiguous. I dont know how easy it is to provide a buffer overflow in Basic but if your going to give a basic example at least give it in BASIC!

• There was a computer language called "English," should we avoid referring to it? Come to think of it, there are people called English, we better not refer to either the computer language or the language we speak or everyone will get really confused! There are no reserved words in English, only in computer languages, and that the word "basic" here was not talking about the language was perfectly clear from reading slightly further. NicM 17:19, 14 September 2006 (UTC).

"It is irrelevent whether buffers are static or dynamic (buffer overflows are the same principle regardless)" 

I agree that overflows are the same regardless but in the context of multiprogramming, use of a static variable for multiple concurrent threads is effectively a buffer overflow by (accidental) default. Each thread overflows 100% by utilizing unintentionally some other threads buffer and that is a completely seperate point for the article. You wouldn't believe the number of situations all over the world in banks and other financial institutions where I have found use of a single save area used for millions of concurrent threads at the same time. These sort of errors dont cause problems "most of the time" but when they do they are virtually untraceable (without a simulator which finds the error immediately). Placing the program code in protected memory helps but there are often still "common storage" areas that might be used in place of dynamic thread storage.

• This is interesting but, as you say, this distinction is a seperate point and not necessary for a first introduction to buffer overflows. It can be covered somewhere in the article, but it isn't necessary to bring it up until the reader understands the general concept. NicM 17:19, 14 September 2006 (UTC).

• • You merely say it is "interesting" but fail to admit that bounds checking (in the conventional sense) fails miserably to catch this error which is precisely to do with the difference between static and dynamic buffers and why I referrred to this as a "special case" in my revised article - and distinguished between static variables and dynamically acquired thread variables early on.

(To let you off the hook - of course, if we extend "bounds checking" to include checking (at exec time) where the first byte of the buffer is located, it could theoretically detect it - but at what cost? - However, short of resorting to a thread-based memory protect key for each byte of memory or a seperate address space for each thread, this is somewhat more challenging and would require a logical 3-way partitioning (at least) to be efficient (protected instructions/shared static/thread. Even then, shared static might be huge and so what protection would each thread have for its temporary "ownership" (purely contextual and temporal) of a small part of it (think of it as territory ownership on earth for a rough analogy)?ken 08:13, 15 September 2006 (UTC)

• • • Using the wrong buffer is not a buffer overflow, it is merely a bug, even if the result may be that the buffer is overflowed. It is worth mentioning in a side note but is not the main point of the article. NicM 15:45, 15 September 2006 (UTC).

I hope I have adequately made my point(s) but there does seem to be an acceptance that there ought be a clean up in the article, it probably should be split three ways programming/avoidance & security - Perhaps even 5 ways if you include testing for overflows and history of exploitation as seperate sections. Personally I think that what was pretty much what I started to do and I hope you accept my Software prevention section as being relevant now after giving it more thought.

• I didn't say your software prevention section is irrelevent, as far as I am concerned it can go into the article (although some refs would be nice, as I said), it is your other restructuring I didn't like. NicM 17:19, 14 September 2006 (UTC).

It would be more fruitful spending our time improving the article than discussing it endlessly here! over to you! ken 13:54, 14 September 2006 (UTC)

• Well, it would be nice to draw up a table of contents before moving text. What about:
  • Lead-in
  • Technical description

    I reckon this should take a simple example in some language (I would say with a byte-wise copy loop) and walk through it, preferably with a state table. It should cover the potential results of buffer overflow (exception, mentioning security flaw briefly but leaving most for next section) and cover bounds checking.

  • Computer security

    How exploits happen, consequences, perhaps a famous example.

  • Detecting and avoiding overflows

    These are much the same as now: language, safe libs, SSP, W^X and friends, ASLR and DPI, monitoring/emulation.

  • Overflows in practice

    History and perhaps some more real-life examples or bugs.

NicM 17:19, 14 September 2006 (UTC).

---

What about something like this? NicM 18:41, 14 September 2006 (UTC).

A buffer overflow occurs when data written to a buffer corrupts the contents of memory addresses outside the buffer, usually those adjacent to the buffer. This commonly happens when copying data, often strings of characters, from one buffer to another, when the programmer has omitted to ensure the buffer is large enough for the data (known as bounds checking). For example, the following snippet of pseudo-code declares a buffer of size five and copies a string of six characters into it. This means that the byte of memory immediately following the buffer is overwritten.

   char  buffer[5]                          /* This is the buffer declaration. The buffer is five characters in size. */
   char  string = "abcdef"                  /* This declares a variable, string, pointing to a string of six characters. */
   int   position = 0                       /* This variable holds the next character to copy from the string into the buffer. When 
                                               this reaches six, the string is complete. */
   char  character = ''                     /* This is a temporary variable to hold the current character from the string before
                                               writing it into the buffer. */
 
 1 do                                       /* This marks the start of the copying loop; execution begins here after looping from line 5. */
 2     character = string[position]         /* Load the character at position into the character variable. */
 3     buffer[position] = character         /* And save the character into the buffer at position. */
 4     position = position + 1              /* Increment the position variable to move on to the next character. */
 5 while position < 6                       /* While the position variable is less than six, loop again to copy the next character. */

After code like this is executed, whatever character appeared in memory after the end of buffer will have been replaced by a "6". The state table below shows the contents of buffer and the position variable as the code executes. The buffer is shown as surrounded by other data, before (B) and after (A).

Line     string       buffer         character        position
1        "abcdef"     "BB_____AA"    '' (nothing)     0
2        "abcdef"     "BB_____AA"    'a'              0
3        "abcdef"     "BBa____AA"    'a'              0
4        "abcdef"     "BBa____AA"    'a'              1
2        "abcdef"     "BBa____AA"    'b'              1
3        "abcdef"     "BBab___AA"    'b'              1
4        "abcdef"     "BBab___AA"    'b'              2
2        "abcdef"     "BBab___AA"    'c'              2
3        "abcdef"     "BBabc__AA"    'c'              2
4        "abcdef"     "BBabc__AA"    'c'              3
2        "abcdef"     "BBabc__AA"    'd'              3
3        "abcdef"     "BBabcd_AA"    'd'              3
4        "abcdef"     "BBabcd_AA"    'd'              4
2        "abcdef"     "BBabcd_AA"    'e'              4
3        "abcdef"     "BBabcdeAA"    'e'              4
4        "abcdef"     "BBabcdeAA"    'e'              5

At this point the buffer is full, five characters have been written. But the string is six characters so the loop continues, like so:

Line     string       buffer         character        position
2        "abcdef"     "BBabcdeAA"    'f'              5
3        "abcdef"     "BBabcdefA"    'f'              5
4        "abcdef"     "BBabcdefA"    'f'              6

The position variable has reached six, so the loop exits and copying stops; it can be seen, however, that the first character after the buffer (the first A) has been overwritten with the sixth character from the string. When a later part of the program attempts to make use of the data in this location, it will retrieve an f character instead of the expected A, which may cause it to behave incorrectly. This is a simplified example; in reality, the data being copied is usually of varying size, which is measured at runtime. If, through accidental or malicious action, the program receives data greater in size than the buffer available, a scenario similar to that demonstrated above happens and a buffer overflow occurs. Buffer overflows may also be caused in other, related, ways. For example, despite having enough space in the buffer for the provided data, the programmer may accidently copy too much—in its most common form a type of off-by-one error—or a program error may cause the incorrect index into the buffer or length of buffer or source data to be calculated.

In most programming languages, buffer overflows are avoided by performing bounds checking before copying data. The length of the data to be copied and of the target buffer are compared and if there is insufficient space remedial action is taken, such as returning an error or truncating the data. Some languages, for example Java, automatically perform bounds checking in all cases; others, including C, provide standard copying functions, such as strncpy, which allow the user to specify the buffer size and automatically truncate data if it is exceeded.

Consequences of buffer overflow may range from a program crash or incorrect behaviour or output to a security compromise................

---

08:13, 15 September 2006 (UTC)ken I think you have placed your computer security section too much "to the fore". There is certainly no harm in mentioning it in the introduction and referring to the later security/exploitation sections. I think it is more important to discuss the various ways to limit the occurence than discuss how others have exploited the loophole first. In an article on "cutting implements" (knives) you wouldn't immediately start talking about all the ways people have killed each other with knives! Similarly, in an article on nuclear physics you wouldnt start talking about Heroshima. I am sure I could probably kill someone with a wax crayon or a plastic bag given half a chance (nothing personal! (: 08:13, 15 September 2006 (UTC)ken)

• I think it is important the reader understands what is happening before you start trying to explain ways to stop it, otherwise they become a bit meaningless. To put it in terms of your metaphor, you wouldn't start an article on stabbing people with knives by talking about famous murders and using body armour, right? You'd start by talking about what happens when someone is stabbed and stabbing techniques. Computer security is probably the most important and notable aspect of buffer overflows, so it does need to be mentioned significantly. NicM 15:45, 15 September 2006 (UTC).

Your comments about "not having enough for a programming section" are now looking somewhat inappropriate You have at least the following topics within it:- technical description, examples, bounds checking (including limitations & performance issues, choice of programming language, static v. dynamic buffers, memory protect keys etc, software protection by simulation) and testing (methods, products & tips to find if you have any exposures, including conditional bounds checking code for instance - best of both worlds

• The technical part crosses both security and programming so it should be a seperate section. I would put your last four suggestions under a section on avoidance/mitigation not a subsection of programming. It is best to avoid subsections unless really necessary. Oh, and no tips, this is an encylopedia not a howto guide. NicM 15:45, 15 September 2006 (UTC).

- I just thought of that one! Ideally, the exec-time conditional test would be executed once only so that unless the condition was met ("Boundschecking=YES bit on"), performance would be unaffected), if it is on, a nice little error message including position number! Obviously, if the overhead isnt always present, further (more complex) buffer start address checks could theoretically be performed in-line with the bounds checking:-

 do while boundschecking (on)
       perform buffer start address checks 
       perform string copies with bounds checking     
 else
       perform string copies
 end

One drawback here is that high level languages may not provide:-

• a) sufficient feedback from operating system about absolute location of buffers in order to check anything
• b) efficient go/nogo switches are easier to implement in Assembler.

What would be nice is for the operating system to provide a call to check "any" absolute address for a number of significant attributes (key protected/program storage/thread storage/etc) to facilitate this form of check. I can't recall such a feature, are you aware of any similar to what I describe ?

• I'm not fully clear what your suggestion is... you want a switch to turn automatic bounds checking on and off? This doesn't seem like an impossibility in any language that has automatic bounds checking, but I am not aware of any that permit it. As far as operating systems go, OpenBSD's ProPolice may be disabled at compile-time, and some of its malloc protections are disabled unless the user specifically turns them on. Or are you saying that each buffer should be bounds-checked only once and the result cached? That would be possible, but you would need to check the souce buffer length was the same which would be expensive. NicM 15:45, 15 September 2006 (UTC).

Sadly, none of this has actually honed the article itself towards what we are (both?) looking for. What I like about WIKIPEDIA is the sense of "I see therefore I do" approach which is interactive and (normally) productive. I get frustrated if I am not actually producing or helping to produce an end product and this to/fro without an actual build up is a tad slow. ken 08:13, 15 September 2006 (UTC) (deluded/ frustrated / fed up / disillusioned!)

• Well, what do you suggest? I have suggested my version of a table of contents with four sections, what sections do you suggest? I really don't see a way to have a straight computer programming/computer security split without a) having a lot of overlap or having a lot that applies to both mentioned in one but not the other c) having related concepts in seperate sections. I don't really understand your issues with my suggestion, it seems to include a place for everything you have mentioned as wanting in the article and to have an obvious logical flow:
  • a large technical description section covering the hows and whys of a buffer overflow in terms of programming (after this the reader understands what a buffer overflow is and how it happens),
  • a section on computer security (after this the reader understands some of how people make use of overflows to compromise security),
  • a section covering avoidance and mitigation techniques (after which the reader undertsnds some of the options available to programmers and OS designers to avoid or limit the problem),
  • and a section with history (which helps the reader to place the material in the previous sections in a historical context)
  • then the standard see also, external links etc give further reading on the topic.
• Is your argument that computer security is not an important topic with regard to buffer overflows? If so, are you sure you are not underestimating the number of security problems they cause? Also, did you look at my example start of a technical description section above? Do you have any comments?
• If you don't want to continue discussing this article, naturally you do not have to: go and work on something else or make some different changes to this article. If you re-add your section on monitoring without doing all the restructuring, I will copyedit it and tidy it up and use it if I ever do then get around to a complete restructuring. Nobody aside from me has objected to it on the talk page. NicM 15:45, 15 September 2006 (UTC).

ken 19:54, 15 September 2006 (UTC) I think I will wait until someone else adds their comments! to get a perspective on this ken 19:54, 15 September 2006 (UTC)

sizeof parentheses

Interesting; I didn't realize that C requires parentheses in that situation. Thanks for letting me know, and my apologies for reverting your change without bothering to double-check first. Neilc 17:19, 24 September 2006 (UTC)

No problem, thanks for your reply. NicM 23:04, 24 September 2006 (UTC).

Note: it doesn't, but I also agree that it is more readable that way. -Anon user (66.127.51.202)

You are wrong. NicM 23:04, 24 September 2006 (UTC).

Yes. I was. I was thinking of sizeof as applied to expressions rather than type names. You are correct. I apologize. Conor H. 23:13, 24 September 2006 (UTC)

No worries :-). NicM 23:18, 24 September 2006 (UTC).

Technical evangelist merged; please help

I have merged your work at [{Technical evangelist]] with Technology evangelist. You might like to drop by and copyedit the new combined article. --Hroðulf (or Hrothulf) (Talk) 10:47, 26 October 2006 (UTC)

Template:FOSS celeb

Now, about the BSD people: on the Linux side, kernel hackers Andrew Morton (computer programmer), Marcelo Tosatti, Greg Kroah-Hartman, Ingo Molnar, Stephen Tweedie, Hans Reiser, and Con Kolivas are not listed in spite of their notability. I will include Robert Love for now, but would ask that we please try to apply the same standards to BSD and Linux hackers. The kernel hackers that I have listed, such as Alan Cox and Maddog Hall, have been very active in promoting open source through magazine articles and speeches. I don't see the same being true of some of the BSD guys. Please keep in mind that one of the criticisms recently levied at the template was that it was going to grow out of control. I have considered splitting it into Linux and BSD templates, but this would not do justice to the people who are not associated with either project, as well as leaving all the cross-platform folk (GNOME, KDE, etc.) in the cold. - Samsara (talk • contribs) 17:39, 19 November 2006 (UTC)

I was just writing a comment on this on the talk page but I will put it here instead. I don't necessarily think making speeches and writing articles a key figure in history makes, nor does just writing code for an existing project. I think they have to have actually done something unique or significant, as well as being well-known. So, on reflection PHK is probably better out (although he is probably the most well-known *BSD dev aside from Theo de Raadt). I'm not too sure about Jon Hall, but I think he is probably alright. So is Alan Cox, he hasn't done much aside from code, but he is probably the most well-known Linux figure aside from Linus himself, so I don't object too much. The rest of them, although their contributions to Linux have been significant, are probably better left out. A Template:Linux developer might be a neat idea though. The only person I'm really a little unsure about now is Guido van Rossum: is Python really that significant? What else has he done? NicM 18:03, 19 November 2006 (UTC).

I'm not that sure about him either. I think people see him as an embodiment of (in Raymond's words) the cathedral approach within open source, the benevolent dictator. As an aside, I guess Mark Shuttleworth is a similar figure. Python is growing, but so is Ruby. Why feature van Rossum any more than Yukihiro Matsumoto? So yes, I agree with you. - Samsara (talk • contribs) 18:18, 19 November 2006 (UTC)