libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BUG in ltdl.c - here's a PATCH


From: Albert Chin
Subject: Re: BUG in ltdl.c - here's a PATCH
Date: Fri, 14 Jun 2002 13:47:38 -0500
User-agent: Mutt/1.2.5i

On Fri, Jun 14, 2002 at 01:23:37PM -0500, Bob Friesenhahn wrote:
> On 14 Jun 2002, Lutz Müller wrote:
> > Not quite right. We need to terminate the filename after dir_name got
> > copied over it without a terminating '\0'. That is, you could do a
> >
> > strncpy (filename, dir_name, strlen (dir_name));
> > filename[strlen (dir_name)] = '\0';
> 
> The normal case is that you use strncpy() in order to not overrun the
> target buffer.  That means that the maximum number of characters to
> copy should be based on the target buffer size and not on the length
> of the source string.  If filename was statically allocated, you could
> use sizeof() to determine the target buffer size, otherwise you will
> need to remember the size of the allocation.
>
> Your example is no better than strcpy().  It allows overrunning the
> target buffer. 
> 
> Perhaps strncpy() is overused and it would be more useful to use
> strlen() to verify that the source string will entirely fit in the
> destination buffer so that an error can be flagged if the string will
> be truncated.  An error report is usually more valuable than a
> truncated string.
> 
> Another possibility (if string concatenation is not being performed)
> is to use strdup() so that the allocation and copy may be performed in
> one operation.

Do we need the strncpy guard if we have the preceding test?
  if (lendir +1 +lenbase >= filenamesize)

Anyway, deciding on a difference between strcpy/strdup is how many
times we currently call LT_EMALLOC through the loop. Having strdup
would certainly make the code cleaner.

-- 
albert chin (address@hidden)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]