🚀 go-pugleaf

> val = fscanf(file,"%*[ \t\n]%74[abcdefghijklmnopqrstuvwxyz
> ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789]", namebuf);
> 
> In case your input does not begin with space, tab or newline, scanf will 
> return 0 which is not right, since "*" should match "0 or more" .

I presume the "0 or more" comes from the ULTRIX manual; I see nothing like
it in the 4.3BSD manual.  The 4.3BSD manual does not indicate one way
or the other whether a zero-length match for a "%[]" item is
considered a successful or failed match.  If it is a successful
match, then a zero-length match of the "%74[abc...]" item is also a
successful match.

It sounds like they may be using the S5 version of "doscan", either
for S5 compatibility or because it fixes a number of bugs in the 4.3
version.  The SVID says for "%[]" conversions:

	...At least one character must match for this conversion to
	be considered successful.

and the October 1, 1986 ANSI C draft says:

	...If the length of the input item is zero, the execution of
	the directive fails: this condition is a matching failure,
	unless an error prevented input from the stream, in which
	case it is an input failure.

In other words, this behavior is most likely here to stay.  The bug
is in the Pascal runtime, not in "scanf".
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com