Talk:Off-by-one error

Article title

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

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 62.153.205.205 (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. 93.89.134.240 (talk) 08:27, 12 September 2013 (UTC)

Early example

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

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)

If the row of telegraph poles connects two houses, there will be gaps between the first and last poles and the respective houses. 5.146.174.119 (talk) 12:43, 15 May 2023 (UTC)

Obi-wan error?

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 86.184.51.152 (talk) 10:24, 3 October 2014 (UTC)

Fence post or lamp post?

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

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

that extra inch

I removed "that extra inch you didn't really want" as a synonym of Off-by-one-error, added by 46.39.230.238 on 18 July 2016 with no explanation. I don't see any references to this phrase except for this page itself. It looks like vandalism. I'm happy to put it back if anyone can cite a real usage. Faught (talk) 18:40, 21 December 2017 (UTC)

This is very difficult to understand

The article starts off like this:

An off-by-one error or off-by-one bug (known by acronyms OBOE, OBO, OB1 and OBOB) is a logic error involving the discrete equivalent of a boundary condition.

Then it goes on to get worse, it seems very much like word salad. Rajasayes (talk) 03:31, 2 May 2022 (UTC)

I reformulated the intro to make it more readable. Is it better now?

I removed the mention of boundary condition, which I also found dubious (maybe needs better explanation). I also removed the link to "zero" and "one" articles and replaced it with a link to zero-based numbering, which I believe is much more relevant. Ondrej Kincl (talk) 19:11, 12 August 2023 (UTC)