|WikiProject Computer Security / Computing||(Rated Start-class)|
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
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 22.214.171.124 (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. 126.96.36.199 (talk) 08:27, 12 September 2013 (UTC)
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.
- 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.
- 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)
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 188.8.131.52 (talk) 10:24, 3 October 2014 (UTC)