[comp.unix.wizards] scanf quiz winner!!!!

franco@MIKEY.BBN.COM (Frank A. Lonigro) (07/28/87)

	Sorry!! But your winner is a loser!!! {|-)>  

	The scanf line that was exclaimed to be a winner once again
restricts the character strings to not have a certain char in them
in this case a 'newline' (\n).  This example follows:
		scanf("%s %[^#] %*c %[^\n]", s1, s2, s3);

	I have stated the correct way to handle the problem in a
recent posting to unix-wizards.  That example follows:
		scanf("%s %[^#] %*c %[\001-\177]", s1, s2, s3);
                                      ^^^^^^^^^
Please note that the format string doesn't restrict any chars from
appearing in the final string except the NULL.

	Also, please note that an obvious change to the above example
will not work:
		scanf("%s %[^#] %*c %[^\0]", s1, s2, s3);
                                      ^^^
This format string says the same thing as the previous(allow all
chars BUT the NULL) but with one flaw.  The format string is terminated
by a NULL prematurely and the _doscan function will not see the closing
']' square bracket.  Fortunately I discovered this problem when I moved
our software from Ultrix 1.1 to 1.2, i.e.. The "%[^\0]" worked correctly
under 1.1 but failed under 1.2 and all the scanf calls that used that
format had to be changed to "%[\001-\177]", an easy task. {|-)>

                                                          ^- Pat Sajak with
                                                             punk sunglasses

franco%bbn.com@relay.cs.net

ugbinns@sunybcs.uucp (Leonard Binns) (07/31/87)

In article <8530@brl-adm.ARPA> franco@MIKEY.BBN.COM (Frank A. Lonigro) writes:
>	Sorry!! But your winner is a loser!!! {|-)>  

I don't think so Frank!


>	The scanf line that was exclaimed to be a winner once again
>restricts the character strings to not have a certain char in them
>in this case a 'newline' (\n).  This example follows:
>		scanf("%s %[^#] %*c %[^\n]", s1, s2, s3);

I look at this as a *feature* not a drawback!
I assumed that the newline was the final delimeter in the third string.
This makes more sense (to me) than your solution since mine can be used
to scan more than *one* set of input during execution.

In your solution, the final delimeter for the third string is EOF,
which makes scanning more than one input line difficult to say the least.

>	I have stated the correct way to handle the problem in a
>recent posting to unix-wizards.  That example follows:
>		scanf("%s %[^#] %*c %[\001-\177]", s1, s2, s3);
>                                      ^^^^^^^^^
>Please note that the format string doesn't restrict any chars from
>appearing in the final string except the NULL.
>
>franco%bbn.com@relay.cs.net

Well if you find it more useful to be able to only scan *one* set of input,
more power to you. And before you jump the gun I think you really should
get your facts straight before you denounce someone so positively. Did you? :-|

	Stuart, what's your ruling??
	-Len Binns

allbery@ncoast.UUCP (Brandon Allbery) (08/02/87)

As quoted from <8530@brl-adm.ARPA> by franco@MIKEY.BBN.COM (Frank A. Lonigro):
+---------------
| 	The scanf line that was exclaimed to be a winner once again
| restricts the character strings to not have a certain char in them
| in this case a 'newline' (\n).  This example follows:
| 		scanf("%s %[^#] %*c %[^\n]", s1, s2, s3);
| 
| 	I have stated the correct way to handle the problem in a
| recent posting to unix-wizards.  That example follows:
| 		scanf("%s %[^#] %*c %[\001-\177]", s1, s2, s3);
+---------------

NO!  This will attempt to read the entire remaining part of the file into
s3; since almost always what is wanted is the rest of the LINE, the use of
\n is correct.  Your example will cause a core dump if someone uses it to
read in a magic cookie at the beginning of a file (something like the
infamous #!).
-- 
 Brandon S. Allbery, moderator of comp.sources.misc and comp.binaries.ibm.pc
  {{harvard,mit-eddie}!necntc,well!hoptoad,sun!cwruecmp!hal}!ncoast!allbery
ARPA: necntc!ncoast!allbery@harvard.harvard.edu  Fido: 157/502  MCI: BALLBERY
   <<ncoast Public Access UNIX: +1 216 781 6201 24hrs. 300/1200/2400 baud>>