[Top][All Lists]

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

Re: [PATCH unionfs 3/3] Don't use strncat() with length derived from sou

From: Samuel Thibault
Subject: Re: [PATCH unionfs 3/3] Don't use strncat() with length derived from source string
Date: Mon, 26 Apr 2021 22:10:37 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Sergey Bugaev, le lun. 26 avril 2021 22:34:45 +0300, a ecrit:
> On Mon, Apr 26, 2021 at 9:02 PM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> > > -  strncpy (filepath, path, length);
> > > -  strncat (filepath, filename, strlen (filename));
> > > +  strcpy (filepath, path);
> > > +  strcat (filepath, filename);
> >
> > This is dubious. We should be using safe interfaces where possible.
> To expand a bit on my (an GCC's) reasoning, it makes no sense to use
> strncpy/strncat with length that is derived from the *source* string
> length, such as

> strncat (filepath, filename, strlen (filename));
> because str[n]cat would never copy more than strlen (filename) bytes
> from filename anyway. The intended/safe way to use strncpy is by
> specifying the *destination* buffer size, e.g.
> strcpy (buffer, source, sizeof buffer);
> I could have done just that; but then it makes little sense when the
> buffer size is, too, directly derived from the source string length,
> as in

Err, but wouldn't the compiler be able to determine that the size was
properly computed, and avoid emitting a false-positive warning?

The compiler emitting a warning looks to me like a sign that there might
really be something subtly wrong. Actually sending the output of the
compiler on the list would help us to know more about it.

>  stow.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Applied, thanks!


reply via email to

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