5 ms·

> Note: The table of data was gathered from regex101.com, I didn't test using the actual runtimes. Has anyone confirmed this behaviour directly against the run

> Note: The table of data was gathered from regex101.com, I didn't test using the actual runtimes. Has anyone confirmed this behaviour directly against the runtimes/languages? Newlines at the end of a string are certainly something that could get lost in transit inside an online service involving multiple runtimes.

AtNightWeCode 3y ago
I fail to add carriage return to the test string on that site. Which I guess would be an issue on Windows.
zimpenfish 3y ago
https://go.dev/play/p/Tce1qWjfjOy https://go.dev/play/p/Tce1qWjfjOy matches their results. I've also run that locally against "go1.22.1 darwin/arm64", "go1.21.5 windows/amd64", and "go1.21.0 linux/amd64" with the same result.
coldtea 3y ago
>Newlines at the end of a string are certainly something that could get lost in transit inside an online service involving multiple runtimes. In what way could newlines at the end of a string "could get lost in transit"?
- ghusbands 3y ago
  If you write it to a text file by itself and then read it from that text file, each runtime can have a different definition of whether a newline at the end of the file is meaningful or not. Under POSIX, a newline should always be present at the end of a non-empty text file and is not meaningful; not everyone agrees or is aware. There are plenty of other ways, too; bugs happen.
  - coldtea 3y ago
    Ideally no runtime should alter strings passing through ("in transit") from one runtime to another - unless it does some processing on them.
ghusbands 3y ago
I've now tested C#, directly, and got the same result as the article. It also documents the behavior: > The ^ and $ language elements indicate the beginning and end of the input string. The end of the input string can be a trailing newline \n character.
burntsushi 3y ago
Yes, and with more regex engines: https://github.com/BurntSushi/rebar/blob/177f5d55e916964b9c44ba7286ea319811041b2b/benchmarks/definitions/test/func.toml#L46-L80 https://github.com/BurntSushi/rebar/blob/177f5d55e916964b9c4... Beyond what's in the OP, that includes RE2, Hyperscan, D's std.regex, ICU, Perl, Python's third party `regex` package, and `regress`.

AtNightWeCode 3y ago

I fail to add carriage return to the test string on that site. Which I guess would be an issue on Windows.

zimpenfish 3y ago

https://go.dev/play/p/Tce1qWjfjOy https://go.dev/play/p/Tce1qWjfjOy matches their results. I've also run that locally against "go1.22.1 darwin/arm64", "go1.21.5 windows/amd64", and "go1.21.0 linux/amd64" with the same result.

coldtea 3y ago

>Newlines at the end of a string are certainly something that could get lost in transit inside an online service involving multiple runtimes. In what way could newlines at the end of a string "could get lost in transit"?

ghusbands 3y ago
If you write it to a text file by itself and then read it from that text file, each runtime can have a different definition of whether a newline at the end of the file is meaningful or not. Under POSIX, a newline should always be present at the end of a non-empty text file and is not meaningful; not everyone agrees or is aware. There are plenty of other ways, too; bugs happen.
- coldtea 3y ago
  Ideally no runtime should alter strings passing through ("in transit") from one runtime to another - unless it does some processing on them.

ghusbands 3y ago

I've now tested C#, directly, and got the same result as the article. It also documents the behavior: > The ^ and $ language elements indicate the beginning and end of the input string. The end of the input string can be a trailing newline \n character.

burntsushi 3y ago

Yes, and with more regex engines: https://github.com/BurntSushi/rebar/blob/177f5d55e916964b9c44ba7286ea319811041b2b/benchmarks/definitions/test/func.toml#L46-L80 https://github.com/BurntSushi/rebar/blob/177f5d55e916964b9c4... Beyond what's in the OP, that includes RE2, Hyperscan, D's std.regex, ICU, Perl, Python's third party `regex` package, and `regress`.