On Tue, Feb 06, 2001 at 01:21:00PM -0500, Bruce Momjian wrote:
> > > *** fe-exec.c 2001/01/24 19:43:30 1.98
> > > --- fe-exec.c 2001/02/06 02:02:27 1.100
> > > ***************
> > > *** 2035,2041 ****
> > > if (len > 23)
> > > len = 23;
> > > strncpy(buf, res->cmdStatus + 7, len);
> > > ! buf[23] = '\0';
> > >
> > > return buf;
> > > }
> > > --- 2035,2041 ----
> > > if (len > 23)
> > > len = 23;
> > > strncpy(buf, res->cmdStatus + 7, len);
> > > ! buf[len] = '\0';
> > >
> > > return buf;
> > > }
> > >
> >
> > Hmm, is there some undocumented feature of strncpy that I don't know
> > about, where it modifies the passed length variable (which would be hard,
> > since it's pass by value)? Otherwise, doesn't this patch just replace
> > the constant '23' with the variable 'len', set to 23?
>
> What if len < 23?
If len < 23, then strncpy will have terminated the destination
already. Poking out buf[23] just compensates for a particular
bit of brain damage in strncpy. Read the man page:
The strncpy() function is similar [to strcpy], except that not
more than n bytes of src are copied. Thus, if there is no null
byte among the first n bytes of src, the result wil not be
null-terminated.
Thus, the original code is OK, except probably the literal "23"
in place of what should be a meaningful symbolic constant, or
(at least!) sizeof(buf) - 1.
BTW, that static buffer in PGoidStatus is likely to upset threaded
client code...
<ob-ed>
To null-terminate strings is an Abomination.
</ob-ed>
Nathan Myers
[EMAIL PROTECTED]
