You know that GNU libc to this day essentially calls strlen() on every call to sscanf(), which is pretty much the same issue? And that this behaviour, present in many other implementations of standard C library (including Microsoft's), was responsible for e.g. slow JSON parsing in some very popular online games [0]? Does that mean glibc is still not production-ready?

[0] https://news.ycombinator.com/item?id=26296339

▲

dleslie 2 days ago | parent [-]

sscanf is quadratic in the worst case, and has been flagged along with the bulk of the rest of the libc string support as being hazardous or potentially harmful. Its continued existence is for compatibility, but new projects should not use it.

▲

Joker_vD 2 days ago | parent [-]

First of all, sscanf doesn't need to be quadratic in the worst case; it absolutely can work without finding the NUL-terminator first. Second, I'd like to see that list of "flagged along with the bulk of the rest of the libc string support as being hazardous or potentially harmful" functions. Does this list include strchr()? Because if yes, your original argument fails to stand.

▲

dleslie 2 days ago | parent [-]

strchr relies on null termination and returns a pointer. It's absolutely vulnerable to abuse. There are many CVEs related to the use of strchr.

▲

Joker_vD a day ago | parent [-]

So why do you consider zig's less-than-performant implementation of strchr to be so egregious as to serve as its condemnation while you give glibc a free pass for exactly the same blunder? Why the double standards? In fact, it's even worse with glibc because it's four times as old as zig.

	▲	dleslie a day ago \| parent [-]
		It's not a problem in isolation. And like I said, the c standard string library is generally considered harmful and dangerous; it does not get a pass. And besides the stability issues, their response to Bun was enough to make it clear that it is a user hostile project. I would never trust a vendor that behaved in that manner to a long standing user, financier and advocate.