🚀 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

As quoted from <309@nsta.UUCP> by tom@nsta.UUCP (Tom Gorodecki):
+---------------
| Bug in doscan.o in /lib/libc.a on ULTRIX 1.2 and ULTRIX 2.0.
| Try in you program.c the following line:
| 
| 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" .
+---------------

* means match but don't assign.  As to whether %[ succeeds on match 0 instances,
this appears to be a matter of interpretation; there isn't an answer.  (I
discovered this when UC 0.4.3 used %[ in userfile parsing; I recoded the
getuser() routine to avoid it for 0.4.4.)

In general, it's best not to use fscanf() unless you are absolutely certain
of the file's format.  (News B2.11 is quite fragile in this regard.)  I
would solve it (for anything but Pascal I/O )-: by fgets(), then skip over
leading whitespace and sscanf() the string.  For Pascal, it gets harder;
the "best" way is skip whitespace, then read characters until you match the
longest value-string defined for the scalar type being input.  (If the list
is organized in alphabetical order (or an array of pointers to them is so
organized), this can be done optimally.
-- 
[Copyright 1987 Brandon S. Allbery, all rights reserved] \ ncoast 216 781 6201
[Redistributable only if redistribution is subsequently permitted.] \ 2400 bd.
Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc
{{ames,harvard,mit-eddie}!necntc,{well,ihnp4}!hoptoad,cbosgd}!ncoast!allbery
<<The opinions herein are those of my cat, therefore they must be correct!>>

-> As quoted from <309@nsta.UUCP> by tom@nsta.UUCP (Tom Gorodecki):
-> +---------------
-> | Bug in doscan.o in /lib/libc.a on ULTRIX 1.2 and ULTRIX 2.0.
-> | Try in you program.c the following line:
-> | 
-> | 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" .
-> +---------------

But the following code would work on any unix system I've ever encountered:

	val = fscanf(file, " %74[a-zA-Z0-9]", namebuf);

Whitespace in the format string matches OPTIONAL whitespace in the input
stream.  The %[] format requires that SOMETHING match its scanstring.
The * only means "0 or more" in regular expressions.  In the example
above it is being used to suppress storing the result of the match.