Re: strncpy is not a safe version of strcpy - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: strncpy is not a safe version of strcpy
Date
Msg-id 20131115150927.GA6220@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: strncpy is not a safe version of strcpy  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: strncpy is not a safe version of strcpy  (Kevin Grittner <kgrittn@ymail.com>)
Re: strncpy is not a safe version of strcpy  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
David Rowley escribió:
> On Fri, Nov 15, 2013 at 12:33 PM, Tomas Vondra <tv@fuzzy.cz> wrote:

> > Be careful with 'Name' data type - it's not just a simple string buffer.
> > AFAIK it needs to work with hashing etc. so the zeroing is actually needed
> > here to make sure two values produce the same result. At least that's how
> > I understand the code after a quick check - for example this is from the
> > same jsonfuncs.c you mentioned:
> >
> >     memset(fname, 0, NAMEDATALEN);
> >     strncpy(fname, NameStr(tupdesc->attrs[i]->attname), NAMEDATALEN);
> >     hashentry = hash_search(json_hash, fname, HASH_FIND, NULL);
> >
> > So the zeroing is on purpose, although if strncpy does that then the
> > memset is probably superflous.

This code should probably be using namecpy().  Note namecpy() doesn't
memset() after strncpy() and has survived the test of time, which
strongly suggests that the memset is indeed superfluous.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Turning recovery.conf into GUCs
Next
From: Tom Lane
Date:
Subject: Re: Database disconnection and switch inside a single bgworker