:
As has been said, sscanf gives you additional "shots" at the data, whereas
with scanf you only get one attempt. I have difficulty coming up with
examples as to why one would want to do that. There is a pretty good set of
conversion functions in <stdlib.h> that do things very similar to the things
in sscanf. I could see a beginner who hadn't yet learned of what is in
<stdlib.h> using sscanf instead, since almost everyone has to learn scanf
early on. Even if it is to learn "don't use scanf."
The libraries are kind of like hidden jewels, you wander around and all of a
sudden turn up this wonderful little thing you can do. I think very few
instructors devote much attention to covering *all* the function libraries.
And there is a lot of self teaching in computer languages as well.
So ... try to engage the attention of the guy who wrote the thing that
triggered your attention in the first place.
That might be difficult for Bill to do directly. The two most recent
previous occurrences of "parse" referring to sscanf() in this newsgroup
were committed by me, in the thread "Reading a data file", and I've got
Bill killfiled. On the other hand, the third most recent was by Nobody,
and that was in the thread "scanf and sscanf" which was started by Bill
himself, so it might not have been me he was referring to.
sscanf(), like scanf(), parses the characters passed to it in accordance
with the specified format. As long as you're reading text data whose
format can be easily and accurately described using scanf() format
strings, it's a fairly good way of doing so, except for it's poor
handling of out-of-range numerical data. However, I didn't claim that
it's a good tool for general-purpose parsing tasks. I'd use yacc and lex
(or bison and flex) for anything seriously complicated, such as
correctly parsing C code.