3 ms·
What about parsing an unknown number of at-most-4-digits integers from a string (being careful, as you exemplified)? Isn’t that a reasonable use of sscanf? Do
by 3xccc 6y ago
What about parsing an unknown number of at-most-4-digits integers from a string (being careful, as you exemplified)? Isn’t that a reasonable use of sscanf?
Do I need a full fledged parser for that? No. Does it have to traverse the whole string every time? No, because I’m being very clear about the maximum length of the thing I’m trying to parse.
You cannot not conclude that it’s a bug.
- kazinator 6y agoMy thoughts on that is that the problem is at a level below sscanf; in other words, what else is affected? A mechanism for turning a string in memory into a string should not be taking its length. GBLIC has an extension called fmemopen. The API is: FILE *fmemopen(void *buf, size_t size, const char *mode); This interface smells like it might have the flaw that if someone wants "buf" to come from a null-terminated string, they must measure that string in order to supply the size parameter. I.e. the underlying mechanism is binary, and does not stop at null characters. There needs to be a separate mechanism with a different underlying stream implementation: FILE *fstropen(const char *str); // mode implied: "r" This doesn't require a size. That fmemopen extension points to a solution to the original problem, though non-portable: open the entire buffer of numbers as a stream in one fmemopen call, and then use fscanf to march through it.
- froh 6y agofmemopen is meanwhile portable and part of posix. https://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/f...