From owner-freebsd-hackers Sun Jan 12 12:03:55 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA17797 for hackers-outgoing; Sun, 12 Jan 1997 12:03:55 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id MAA17792 for ; Sun, 12 Jan 1997 12:03:50 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA26127; Sun, 12 Jan 1997 12:52:08 -0700 From: Terry Lambert Message-Id: <199701121952.MAA26127@phaeton.artisoft.com> Subject: Re: number of lines in a file, given its size To: joerg_wunsch@uriah.heep.sax.de Date: Sun, 12 Jan 1997 12:52:08 -0700 (MST) Cc: hackers@freebsd.org In-Reply-To: from "J Wunsch" at Jan 12, 97 07:57:25 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > > > strdup() to the rescue! ... > > > > > > Failed. Try again. UTSL first. > > > > J"org, you are downright diabolical... > > > > Obviously, I wasn't citing code in this case, only a method of functional > > decomposition. > > But you've got your point wrong. strdup(), as much you prefer it or > not, was _by no means_ the answer to the question. The question was > how much space to allocate for the pointers you get from strdup() or > whatever has been chosen. You can solve this problem with realloc(), > but it seems that the existing solution is, though dirty, much less > overkill. You were the one concerned with the fixed buffer size (apparently as a means of an unlikely stack overflow attack). You were also the one concerned about "readability" for a well defined return value from strcpy(), which everyone reading the code *should* now is the copy target address. strdup() allocates as much space as it needs to; you do not allocate space for pointers from strdup(); strdup() is an allocation function. The very idea of needing to know how much space to allocate to contain the result of an allocation which has already occurred is a non-sequitur. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.