Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!udel!new From: new@udel.EDU (Darren New) Newsgroups: comp.sys.amiga Subject: Re: C scanf question Message-ID: <20373@louie.udel.EDU> Date: 24 Jul 89 21:14:16 GMT References: <20201@louie.udel.EDU> <455@tardis.Tymnet.COM> Sender: usenet@udel.EDU Reply-To: new@udel.EDU (Darren New) Organization: University of Delaware Lines: 31 In article <455@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: >You forgot to pass on the most important reason for NOT using scanf. >If you have "char line[80]" and use fscanf(f,"%s",line), what happens if >the input has more than 80 consecutive characters without a tab, blank >or newline? The answer is that some poor variable in your program may >be changed. And if the input is several K of nonblanks, fscanf will >cheerfully overwrite your stack and maybe your entire program as will. > >The only safe way to use the scanf family on untrustworthy data is to >use sscanf on a string read by fgets or equivalent. Two points: 1) fscanf(f, "%80s", line) would do what you want there. 2) in this case, since I'm generating an intermediate file and then reading it back in again, the data is indeed "trustworthy" at least as far as it needs to be. I think the basic problem with my code is this: The Lattice manual says on page L97 that whitespace in the format string will cause input up to the next non-whitespace to be skipped. However, K&R-II (revenge of the ANSI) says that the ANSI scanf ignores whitespace in the format string, which is what appears to be happenning to me. I suspect that the library routine was brought into compliance and the manual was not properly updated. In any case, the point is now somewhat moot in my case, as "line" was to hold a file name and I realised that file names may have whitespace anyway; hence, I parse the beginning with scanf and then use fgets to get the end of the line. Thanks to all for the responses. More stupid questions coming soon to a VDT near you. -- Darren