Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!oliveb!Ozona!chase From: chase@Ozona.orc.olivetti.com (David Chase) Newsgroups: comp.lang.c Subject: Re: retiring gets(3) Message-ID: <32596@oliveb.olivetti.com> Date: 14 Nov 88 22:05:50 GMT References: <8841@smoke.BRL.MIL> <1988Nov11.232629.15414@utstat.uucp> <20588@apple.Apple.COM> Sender: news@oliveb.olivetti.com Reply-To: chase@Ozona.UUCP (David Chase) Organization: Olivetti Research Center, Menlo Park, CA Lines: 34 In article <20588@apple.Apple.COM> desnoyer@Apple.COM (Peter Desnoyers) writes: >Perhaps I'm being naive, but wouldn't changing > char buf[x]; gets( buf); >to > char * buf; buf = malloc( x); gets( buf); >eliminate most (not all) of the security hole associated with gets()? In practice it would make invasion difficult. Do bear in mind that it might not make it impossible; memory allocation may look like a black box to you, but with a little care purposeful overwriting is possible (for example, in testing a new garbage collector we discovered a bug tickled by the collector that (independent of input) consistently appeared at the same line while examining a structure at the same address. The cause? Overrunning of a data structure in the heap.) (Yes, a garbage collector for C -- ~ftp/sun-source/gc.shar@titan.rice.edu It works on Sun3s, Sun4s, Vaxes. Send mail with subject "help" to "archive-server@rice.edu" if you lack FTP access.) What I fail to understand is why you couldn't just as easily write char * buf; buf = malloc(x); fgets(buf, x, stdin); (yes, I know that fgets leaves the newline in the string) People say again and again "but I know how big the input is in my programs, so it's safe to use 'gets'". If you know how big the input is, then you might as well say it. People talk about performing certain hand-optimizations in a habitual way; is it too much to ask people to acquire habits that make their programs more robust? Optimizing a correct program is easier than correcting an optimized program (more fun, too). David