Date: Sun, 12 Jan 1997 12:52:08 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@freebsd.org Subject: Re: number of lines in a file, given its size Message-ID: <199701121952.MAA26127@phaeton.artisoft.com> In-Reply-To: <Mutt.19970112195725.j@uriah.heep.sax.de> from "J Wunsch" at Jan 12, 97 07:57:25 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701121952.MAA26127>