TIP: Click on subject to list as thread! ANSI
echo: aust_c_here
to: David Nugent
from: Kieran Haughey
date: 1996-01-05 08:53:24
subject: c

On 02 Jan 96 16:44, David Nugent wrote to Kieran Haughey:

Hi David,

DN>> fgets() is only a little extra typing, and performs the
DN>> same functionality and is safe because you can limit
DN>> input (although exactly what you do with characters after
DN>> the 99th is up to you). There is also no reason to assume
DN>> that stdin is a terminal/keyboard - someone may have
DN>> redirected it from elsewhere.

KH>> Yes, but isn't gets() taking from the stdin anyway?....

DN> Sure, it's always taken from stdin, but what if stdin is a file?  That's 
DN> what I was saying:

DN>     program  means stdin is attached to a file.

I forgot about the redirection factor :)..

KH>> so either way fgets(buffer,100,stdin); would be roughly
KH>> the same as gets(buffer); except for lengths...

DN> Yes. But that "except for ..." is not trivial, however. :-)

:).. True True..

DN>> Summary: gets() is dangerous - don't use it.

KH>> Thanx, I have never seen anyone elsewhere being warned
KH>> about this, so I would have continued to use that
KH>> dangerous little command :).. > fixed it up or anything like that??>..

DN> The problem is that it was made part of the ANSI standard back in 1989 with 
DN> lots of legacy C code exiting at the time that used gets(). Consequently, 
DN> any ANSI/ISO conforming compiler must supply it.

Yeah, Paul mentioned this to me..  

DN> I'm surprised you haven't seen warnings though - most compiler vendors 
DN> actually *do* say something about this in the documentation.

Well according to the docs I have read so far for Turbo C, I haven't found
anything about gets... Also all the books I have read has used either gets
or scanf..


KH>> and any idea
KH>> what's the story on using fscanf over scanf?.. I heard
KH>> that fscanf is safer or something...

DN> No idea on that one - implementations vary widely, but I'd be surprised if 
DN> scanf() differed much from fscanf() from stdin.

Thinking about it I doubt there would be any difference....

DN> The scanf() functions are difficult to use at best, and something probably 
DN> best avoided by a novice user (use fgets()). They are, however, quite 
DN> powerful parsing functions and can be pretty useful if used correctly - 
DN> they can reduce a lot of complex parsing code to a single line of code. If 
DN> you're just grabbing strings, then I'd suggest sticking with something 
DN> simple like fgets(). Even grabbing numbers is easier with fgets() and 
DN> atoi/atol (or similar) - the *scanf() form of input usually has some 
DN> undesirable side-effects when use interactively since it stops at the first 
DN> non-numeric character when looking for numeric input and so on, so you can 
DN> easily flush the input stream, prompt again and get fresh input and so on.

I have never liked the idea of using scanf, mainly for the fact of it's
unpredictability...I would prefer fgets with sprintf... to get it all out..
you might lose a bit of speed, but it would hardly be noticable...

DN> Besides, if you grab a line of input, you can always parse it with 
DN> sscanf(). This is the approach I've always preferred since you're not 
DN> fiddling about with stdio file states and don't have to worry about left 
DN> over data.

 ..
ÿ
Happy New Year,
Kieran

3:711/413.17{at}fidonet
@EOT:

--- MsgedSQ 3.30
* Origin: -=> The Last Stand Against Sanity <=- (3:711/413.17)
SEEN-BY: 50/99 620/243 623/630 711/401 409 410 413 420 423 430 510 808 809
SEEN-BY: 711/932 934 712/515 713/888 714/906 800/1 7877/2809
@PATH: 711/413 808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.