3 ms·
Yes, but it's not scanning the entire string, it's scanning at most 256 bytes. In MSVC, the number of bytes scanned is `M*N` where M is the number of calls to s
by Jasper_ 6y ago
Yes, but it's not scanning the entire string, it's scanning at most 256 bytes. In MSVC, the number of bytes scanned is `M*N` where M is the number of calls to scanf and N is the size of the file. In musl, N is now 257, no matter the size of the file. Compared to ~10MB of data, that's basically free.
Sure, it's scanning a bit more than maybe it needs to, but it's much closer to a non-scanning libc in the amount of data it's consuming.
- JdeBP 6y agoAnd this will be the third time that I've written the phrase "not entirely free of this behaviour", in comparison with the implementations that are entirely free of this behaviour.
- wnoise 6y agoIt's not entirely free of overhead. The overhead is constant per invocation though, so it's entirely free of _quadratic_ behavior. Which is what's being discussed.
- JdeBP 6y agoNo, that was not what was being discussed, neither here nor in that discussion. See https://news.ycombinator.com/item?id=26297612 https://news.ycombinator.com/item?id=26297612 . None of us mentioned quadratic behaviour. We are talking about sscanf() calling strlen(), and in the original discussion why.
- wnoise 6y agoSure, the quadratic behavior is attached to the "calling sscanf in a loop". The point is linear behavior for a call to sscanf. Which isn't the case for musl. Nor does musl call strlen, or even effectively call it. It will bizarrely scan for a NUL in up to 256 bytes ahead of where in the string it is currently. But that's not actually the same behavior as calling strlen or having other linear behavior.