Talk:Off-by-one error

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer Security / Computing  (Rated Start-class)
WikiProject icon This article is within the scope of WikiProject Computer Security, a collaborative effort to improve the coverage of computer security on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing.

Article title[edit]

Off-by-one error was deleted and off by one error was moved to that title as suggested in vfd discussion. See: Wikipedia:Votes for deletion/Off-by-one error -- Wile E. Heresiarch 20:50, 26 Jun 2004 (UTC)

C programming language[edit]

Someone familiar with C, please adapt the "security implications" code so it's more readable to those of us who don't know C (should use pseudocode). ~ Booya Bazooka 06:33, 24 August 2006 (UTC)

I can add some pseudocode here but the most common instance by far of this sort of off by one error resulting in a security critical buffer overflow is in the C programming language using the stand libary strncat call, and it may have less meaning in the pseudo code, I'll try it out though and put it here for comments in an hour or so --Michael Lynn 03:17, 31 October 2006 (UTC)

The whole 'security implications' section is fatally flawed. "A common misconception with strncat is that the guaranteed null termination will not write beyond the maximum length. In reality it will write a terminating null character one byte beyond the maximum length specified. " is total nonsense. Whoever wrote it has a flawed understanding of the relationship the strncat 'n' parameter bears with strncat behaviour. Quoting the manpage: "The strncat() function is similar, except that it will use at most n characters from src;". In other words n is not the size of the destination, and a NULL will *always* be written 'one byte beyond'. Jwmartnet (talk) 23:58, 12 April 2011 (UTC)

Possibly overwriting of the frame pointer has nothing to do with endianness, it only depends on the stack growth direction. — Preceding unsigned comment added by (talk) 13:44, 13 February 2012 (UTC)

The 'security implications' section is still very unclear. It fails to explain the underlying issue which is that strings in C are null terminated, and so buffers need to be one character longer than the longest string that they're intended to contain. There is a valid point in the example, which is that strncpy to a buffer of size n will never cause a buffer overrun, whereas strncat to the same buffer may do, but "the C library ... is not consistent with respect to whether one needs to subtract 1 byte" a very muddled way of describing it. The library has different functions for different purposes, and as such the meaning of the parameters varies. (talk) 08:27, 12 September 2013 (UTC)

Early example[edit]

I found an early (8th century) example of a fencepost error in Alcuin of York's Propositiones ad Acuendos Juvenes, Problem 15 (de homine). The question asks: if a man turns his plow six times, how many furrows has he made? Alcuin's version gives 6, but Bede's version (correctly) gives 7.

I don't know if this historical example would improve the article; for now I'll just leave this here.

CRGreathouse (t | c) 15:40, 5 March 2010 (UTC)

An earlier example is wikilinked here from Julian calendar, describing an error started at about 46 BC and not fixed until as late as 8 AD:

Although the new calendar was much simpler than the pre-Julian calendar, the pontifices apparently misunderstood the algorithm for leap years. They added a leap day every three years, instead of every four years. According to Macrobius, the error was the result of counting inclusively, so that the four-year cycle was considered as including both the first and fourth years; perhaps the earliest recorded example of a fence post error.

Mark Hurd (talk) 17:01, 5 October 2011 (UTC)

Circular fence[edit]

How many posts required for a fence in a circle of 100 meters circumference, with the posts 10 meters apart? Bizzybody (talk) 09:44, 16 June 2010 (UTC)

I will answer the above and question the (unsourced) statement below at the same time:
"If you have n telegraph poles, how many gaps are there between them? The correct answer may be n − 1, n, or n + 1, depending on the conditions."
The answer would be n if they where arranged along a closed curve (answering the above question: 100/10 = 10 = the number of gaps = the number of posts, if you can ignore their diameters), and n-1 if arranged along a non-closed curve.
But how can you get n+1 gaps between n poles?
To rephrase: the ambiguity arises because there is an implicit assumption that "gaps" are only considered between "adjacent" poles and the first and last pole may or may not be considered "adjacent". But what other possibilities can there be unless you consider gaps between non-adjacent poles (in which case there can a lot more gaps than just n+1)? AlexFekken (talk) 08:18, 27 December 2013 (UTC)

Obi-wan error?[edit]

Seriously? No mention in the article of the humourous synonym 'Obi-wan error'? That's a bit like not mentioning the nickname "Chewie" in the article on "Chewbacca". — Preceding unsigned comment added by (talk) 10:24, 3 October 2014 (UTC)

Fence post or lamp post?[edit]

I've always heard it as a lamp post, and never a fence post. That's in many years of software in the UK - is this a regional variation? Number774 (talk) 16:47, 29 August 2015 (UTC)

New image[edit]

I created a new image Fencepost error 01.svg to be used on de:Zaunpfahlfehler. Feel free to use it here too if you like. --Neitram (talk) 12:33, 20 June 2017 (UTC)