Scanning the first argument returns immediately (with a 0, since the source
wasn't a digit), and it then scans for the second argument. Passing a
non-numeric argument will not terminate all subsequent processing.
|> I would not have expected Sscanf() to return 2.
|Scanning the first argument returns immediately (with a 0, since the source
|wasn't a digit), and it then scans for the second argument. Passing a
|non-numeric argument will not terminate all subsequent processing.
|> But why did the whole thing wind up returning 2?
|Because it assigned 0 to number and "fo" to unit.
That's unlike the RTF's swscanf() (isn't it?). I can live with it but I'll have
to learn that Sscanf() return value alone isn't sufficient to determine if all
the numeric fields specified in the format string were actually found in the
target string. Do you use that feature (zeroing/counting numeric fields that
were specified but not found) to advantage?
Does that Sscanf support the %n? I use int endofstring; sscanf(buf, "......
%n", ....., &endofstring) and check buf[endofstring] for '\0'
On Sun, Mar 27, 2011 at 19:18, rconn <> wrote:
> ---Quote (Originally by vefatica)---
> That's unlike the RTF's swscanf() (isn't it?)
> ---End Quote---
> WAD -- Sscanf is different in dozens of ways from the RTL version.
> If I wanted RTL behavior, I would have used the RTL! Every difference in
> Sscanf is deliberate because I needed it for a particular use -- if you need
> RTL behavior, use the RTL (or write your own).