Context
odin: dev-2026-08
OS: Ubuntu 24.10, Linux 6.17.0-19-generic
Backend: LLVM 19.1.1
Expected Behavior
substring_from(s, rune_start) should succeed with an empty result when rune_start == rune_count(s), the same way s[len(s):] is a valid empty slice.
The doc comment says ok reports "whether the rune indexes where in bounds of the original string", which could be read as excluding the one-past-the-end index. But substring already treats that index as in bounds, tests/core/strings/test_core_strings.odin (line) pins substring("Hello", len("Hello"), len("Hello")) == ("", true) , so substring_from should be consistent with it.
Current Behavior
For ASCII strings it returns ok = false instead of succeeding. For strings with multi-byte runes it's worse: it returns a wrong, non-empty, truncated substring instead of an empty one.
Failure Information
Steps to Reproduce
- Run the snippet below.
substring_from("hello", 5) returns ("", false) — expected ("", true).
substring_from("héllo", 5) returns ("o", false) — expected ("", true).
Live repro: https://godbolt.org/z/415EzMW1h
Failure Logs
package main
import "core:strings"
import "core:fmt"
main :: proc () {
fmt.println(strings.substring_from("hello", 5)) // want ("", true), got ("", false)
fmt.println(strings.substring_from("héllo", 5)) // want ("", true), got ("o", false)
}
Related to #6189, which reported a similar bug in substring, that specific case is already fixed on master, but the same root cause is still present in substring_from and for non ASCII strings.
Context
Expected Behavior
substring_from(s, rune_start)should succeed with an empty result whenrune_start == rune_count(s), the same ways[len(s):]is a valid empty slice.The doc comment says
okreports "whether the rune indexes where in bounds of the original string", which could be read as excluding the one-past-the-end index. Butsubstringalready treats that index as in bounds,tests/core/strings/test_core_strings.odin(line) pinssubstring("Hello", len("Hello"), len("Hello")) == ("", true), sosubstring_fromshould be consistent with it.Current Behavior
For ASCII strings it returns
ok = falseinstead of succeeding. For strings with multi-byte runes it's worse: it returns a wrong, non-empty, truncated substring instead of an empty one.Failure Information
Steps to Reproduce
substring_from("hello", 5)returns("", false)— expected("", true).substring_from("héllo", 5)returns("o", false)— expected("", true).Live repro: https://godbolt.org/z/415EzMW1h
Failure Logs
Related to #6189, which reported a similar bug in
substring, that specific case is already fixed on master, but the same root cause is still present insubstring_fromand for non ASCII strings.