View source for Talk:Off-by-one error

{{WikiProject banner shell|class=Start|
{{WikiProject Computer Security|importance=}}
}}
==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]] -- [[User:Wile E. Heresiarch|Wile E. Heresiarch]] 20:50, 26 Jun 2004 (UTC)

==C programming language==
Someone familiar with [[C programming language|C]], please adapt the "security implications" code so it's more readable to those of us who don't know C (should use pseudocode). ~&nbsp;[[User:Booyabazooka|Booya <sup>Bazooka</sup>]] 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 --[[User:Abaddon314159|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 <code>strncat</code> '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'.
[[User:Jwmartnet|Jwmartnet]] ([[User talk: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.  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/62.153.205.205|62.153.205.205]] ([[User talk:62.153.205.205|talk]]) 13:44, 13 February 2012 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

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. [[Special:Contributions/93.89.134.240|93.89.134.240]] ([[User talk: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 <i lang="la">[[Propositiones ad Acuendos Juvenes]]</i>, 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.

[[User:CRGreathouse|CRGreathouse]]<small> ([[User talk:CRGreathouse|t]] | [[Special:Contributions/CRGreathouse|c]])</small> 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: 
:{{quote|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.}}
: [[User:Markhurd|Mark Hurd]] ([[User talk:Markhurd|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? [[User:Bizzybody|Bizzybody]] ([[User talk: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)? [[User:AlexFekken|AlexFekken]] ([[User talk: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. [[Special:Contributions/5.146.174.119|5.146.174.119]] ([[User talk: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".  <span style="font-size: smaller;" class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/86.184.51.152|86.184.51.152]] ([[User talk:86.184.51.152|talk]]) 10:24, 3 October 2014 (UTC)</span><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== 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?
[[User:Number774|Number774]] ([[User talk:Number774|talk]]) 16:47, 29 August 2015 (UTC)

== New image ==

I created a new image [[File:Fencepost error 01.svg|300px]] to be used on [[:de:Zaunpfahlfehler]]. Feel free to use it here too if you like. --[[User:Neitram|Neitram]] ([[User talk: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 [[User:46.39.230.238|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. [[User:Faught|Faught]] ([[User talk:Faught|talk]]) 18:40, 21 December 2017 (UTC)

== This is very difficult to understand ==

The article starts off like this:
<blockquote>
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. 
</blockquote>
Then it goes on to get worse, it seems very much like word salad. [[User:Rajasayes|Rajasayes]] ([[User talk: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. [[User:Ondrej Kincl|Ondrej Kincl]] ([[User talk:Ondrej Kincl|talk]]) 19:11, 12 August 2023 (UTC)

== zero-based indexing is where off-by-one issues magnify ==

Javascript uses <code>0 - 11</code> to represent <code>Jan - Dec</code> because it's a zero-based indexing language. I've seen (some stackoverflow thread) '''<code>JS</code>''' <code>regex</code> code like this 

 function getDaysInMonth2(m, y) {
     return /8|3|5|10/.test(--m)?30:m==1?(!(y%4)&&y%100)||!(y%400)?29:28:31;
 }

Needing to write <code>regex</code> using

 3 | 5 | 8 | 10
to get
 April | June | Sept | Nov

and specifying '''Feb'''-specific logic with

 m == 1

is just begging for a off-by-one issues carnival, since one has to remember to '''''down-adjust''''' it when parsing date or datetime strings, but then also '''''up-adjust''''' it one more time upon formatted output. The '''ISO 8601''' standard pertaining to expressing dates, time, and datetime intervals, also specific months to be '''01 - 12''' - a 1-based indexing language is already compliant with ISO 8601 without doing anything when it comes to counting months, while '''''certain''''' zero-based indexing languages will be constantly shifting the values +/- 1 (more on this point further down).

None of the 5 months with fewer than 31 days are adjacent to each other whatsoever, no matter how much wrap-around is being applied, so the usual argument in favor of zero-based indexing about "half-open intervals" isnt of much help. To make matters worse, the per-loop increment amount also isn't constant, since the short months are the even-numbered ones when it's before August, or the odd months on or after August (if we're counting 1-12 for Jan-Dec).

<code>Python</code> is also zero-based indexing but still has '''01 - 12''' for '''Jan-Dec''' - this is where the issue really manifests itself :

''someone attempting to create a systems (or streaming data pipeline) process where '''python''' and '''javascript''' cross-interact will '''''still''''' have to deal with month-number down-adjust then up-adjust nonstop, even though '''BOTH''' are zero-based indexing languages.''

If there are off-by-one issues lurking in the shadows all over the place, these types of inter-operability  issues '''''JUST''''' among zero-based indexing languages will be far more common than anything originating from 1-based index languages, despite what '''Dijkstra''' loves claiming (because in his mind, no one needs to operate upon discrete set of numeric values that cannot be easily described in existing mathematics nomenclature).

At least there's some merit regarding assigning <code>0 - 6</code> day-of-week values for <code>Sunday - Saturday</code>, since it lines up with how weeks and days of a calendar are presented to the end-users, but I'm simply unaware of any major use case of <code>0 - 11</code> month numbers with incremental benefits so material it fully justifies all the potential off-by-one errors.

ps : as for that <code>for()</code> loop example to showcase why zero-based in superior :

 for (index = 0; index < 5; index++) 
 {
    /* Body of the loop */
 }

One can DIRECTLY adopt this construct for a 1-based indexing language just by consolidating the middle condition with the right-side incrementing expression, without altering any of the thresholds, or comparison operators. :

 for (index = 0; index++ < 5; ) 
 {
    /* Body of the loop */
 }

If anything, the 1-based variant is even cleaner, Only Dijkstra is of the opinion his beloved "half-open intervals" are somehow exclusive to zero-based indexing instead of being equally applicable to both. But unlike half-open this half-open that, 1-based indexing languages are far less prone to off-by-one errors, since it aligns with sensible mappings of the real world. [[Special:Contributions/2603:7000:3C3D:4840:0:0:0:8B3|2603:7000:3C3D:4840:0:0:0:8B3]] ([[User talk:2603:7000:3C3D:4840:0:0:0:8B3|talk]]) 14:27, 10 January 2025 (UTC)