Why Zig over C for Systems Programming

Re:Why Zig over C for Systems Programming by Joker_vD on Friday November 13, 2026 @10:27AM (#50484936)

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

[ Parent | on HN ]

Re:Why Zig over C for Systems Programming by dleslie on Friday November 13, 2026 @10:49AM (#50485258)

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

[ Parent | on HN ]

Re:Why Zig over C for Systems Programming by Joker_vD on Friday November 13, 2026 @12:39PM (#50486917)

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.

[ Parent | on HN ]