chrono VS opengrok

The problem is that this effects higher languages too, because they often build on libc. And on some OSes, they don't have a choice, because the system call interface is unstable and/or undocumented).

For example in rust, multiple time libraries were found to be unsound if `std::env::set_env` was ever called from a multi-threaded program. See:

https://github.com/time-rs/time/issues/293 and https://github.com/chronotope/chrono/issues/499

https://github.com/rust-lang/rust/issues/27970

https://github.com/rust-lang/rust/issues/90308

> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often.

I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the problematic release. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict.

[1] https://github.com/chronotope/chrono

[2] https://github.com/chronotope/chrono/issues/146#issuecomment...

[3] https://github.com/chronotope/chrono/issues/156

[4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...

On that note, it would also be good to configure cargo-deny so that a CI pipeline and any maintainer can easily audit the current dependency versions. Sometimes CVEs require a new major semver (looking at you, time 0.1.x and thus chrono 0.4.x), so it's not enough to rely on people installing the tool with semver-compatible updates. Automatically auditing dependencies is really important, and given how easy cargo-deny makes it, I don't think many projects have any excuse not to configure it.

libc isn't "just a wrapper". Is a massive legacy codebase filled with hacks, UBs and bugs: https://github.com/chronotope/chrono/issues/499

Would love to have people test this, you can leave feedback here: https://github.com/chronotope/chrono/issues/674.

Is it this issue? Any idea what can be done to move this along?

In C, I've had afternoons wasted again and again by the lack of thread-safety invariant in various libraries. I've found countless bugs in Win32 APIs related to them not being thread-safe despite the documentation making no mention of that whatsoever. Including stuff that really, really ought to be thread-safe. We had the recent debacle with localtime_r in chrono which is not thread-safe due to it calling setenv. And you'd think man setenv would tell you that it's not thread-safe? Hah! Perish the thought.

https://github.com/chronotope/chrono/issues/339 for a big breaking issue I came across when using it to process some data at work. Ended up having to use python as it behaved "properly" there.

[4] is not really a usable 'product'. Livegrep (https://github.com/livegrep/livegrep) was inspired by it and is very usable.

[3] used to be a Google open source project as well, but it fell out of maintenance, and Sourcegraph took it over. It powers most of the basic regex/literal search in Sourcegraph.

Mozilla's code is searchable in Searchfox (https://searchfox.org/) which uses the indexer from Livegrep, combined with their own Git indexer and language-specific cross reference databases.

OpenGrok (https://github.com/oracle/opengrok) is also rather well known, but I have found it to have a slightly worse UI than alternatives.

https://oracle.github.io/opengrok/ is open source and very good at huge source base, e.g. for the whole android and linux kernel together, fast and useful.

My job uses https://oracle.github.io/opengrok/ and I'm generally happy with it. It has some problems with special character searches at times but generally does what I want. It's certainly better than code search in our on-prem github instance.

I used it a long time ago, but I see this is still around: https://oracle.github.io/opengrok/

[2] https://about.sourcegraph.com/

[3] https://oracle.github.io/opengrok/

[4] https://github.com/hound-search/hound