Possible scanf bug?

[Phong Vo[drew]]

In article <154 at thor.UUCP>, scjones at thor.UUCP (Larry Jones) writes:
: In article <14285 at ulysses.att.com>, kpv at ulysses.att.com (Phong Vo[drew]) writes:
: > What is uncleared is the meaning of "matched". Since the "" string is legitimate,
: > it is arguable that string matching patterns should always satisfy except for eof.
: > Therefore, it can be argued that sscanf("1,,3","%[^,],%[^,],%[^,]",s1,s2,s3)
: > should return three matches where s2 will contain the null string.
: 
: The ANSI standard makes it clear that %[ matches one or more characters,
: not zero or more.  The descriptions of the printf and scanf functions
: have always been terse and not very precise or informative.  Some of the
: X3J11 members went to great pains to ensure that the ANSI descriptions
: were complete and accurate.
: ----
If this was the choice made by ANSI, then it is a bad choice.
This makes it impossible to write a simple scanf expression 
to parse a record delimitated by some character, for example,
a line from the (UNIXy) /etc/passwd file where some of the
fields may have empty values. With the alleged ANSI requirement,
you must now do it in a more complex loop. Aesthetically,
the requirement is also not nice because it breaks the
invertibility of the following type of pairs of functions:
	printf("%s:%s:%s\n",string1,string2,string3);
	scanf("%[^:]:%[^:]:%[^:]\n",string1,string2,string3);
where stringi's range over the domain of strings without embedded :'s.