Re: strncpy is not a safe version of strcpy

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tomas Vondra <tv(at)fuzzy(dot)cz>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: strncpy is not a safe version of strcpy
Date: 2013-11-15 14:35:03
Message-ID: 20131115143503.GA5888@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-11-15 09:24:59 -0500, Stephen Frost wrote:
> * Tomas Vondra (tv(at)fuzzy(dot)cz) wrote:
> > On 15 Listopad 2013, 1:00, David Rowley wrote:
> > > more focused on trying to draw a bit of attention to commit
> > > 061b88c732952c59741374806e1e41c1ec845d50 which uses strncpy and does not
> > > properly set the last byte to 0 afterwards. I think this case could just
> > > be
> > > replaced with strlcpy which does all this hard work for us.
> >
> > Hmm, you mean this piece of code?
> >
> > strncpy(saved_argv0, argv[0], MAXPGPATH);
> >
> > IMHO you're right that's probably broken, unless there's some checking
> > happening before the call.
>
> Agreed, that looks like a place we should be using strlcpy() instead.

I don't mind fixing it, but I think anything but s/strncpy/strlcpy/ is
over the top. Translating such strings is just a waste of translator's
time.
If you really worry about paths being longer than MAXPGPATH, there's
lots, and lots of things to do that are, far, far more critical than
this.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2013-11-15 14:35:06 Re: additional json functionality
Previous Message Peter Eisentraut 2013-11-15 14:33:55 Re: Logging WAL when updating hintbit