Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!oliveb!sun!gorodish!guy From: guy@gorodish.UUCP Newsgroups: comp.bugs.misc,comp.bugs.4bsd Subject: Re: doscan.o bug in Ultrix 1.2 & 2.0 Message-ID: <22807@sun.uucp> Date: Tue, 7-Jul-87 14:25:29 EDT Article-I.D.: sun.22807 Posted: Tue Jul 7 14:25:29 1987 Date-Received: Thu, 9-Jul-87 06:28:15 EDT References: <309@nsta.UUCP> Sender: news@sun.uucp Lines: 32 Xref: utgpu comp.bugs.misc:58 comp.bugs.4bsd:396 > 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