«

On Feb 16, 12:05*pm, nroberts <roberts.n...@gmail.com> wrote:
> Consider:
>
> char const* f(char const* incoming)
> {
> * static char buf[MAX];
>
> * strncpy(buf, incoming, strlen(incoming));
>
> }
>
> Is there ANY reason to use strncpy like that? *I'm working on a
> project that has such uses all throughout it and before I tell the
> team leader that he's using a basic C function incorrectly I thought
> I'd make sure I'm right.

When you're working with fixed width character buffers, use a fixed
width strlen.

size_t c_strnlen( const char* str, size_t n )
{
const char* p;
p = memchr( str, '\0', n );
return p ? (size_t)( p - str ) : n;
}

Then use the following

strncpy(buf, incoming, c_strnlen(incoming, sizeof (buf)));

Of course, this replaces the potential of a buffer overrun with
truncation, which can lead to other subtle problems.

An alternative is to use something like 'strlcpy', if you want to
guarantee a '\0' character at the end of the string.

Best regards,
John D.

On 16.02.2012 19:34, Anders Wegge Keller wrote:
> "A. K."<> writes:
>
>> On 16.02.2012 18:57, Anders Wegge Keller wrote:
>
>>> buf[MAX] = 0;
>
> buffer overflow !!! )
>
> If you got to have them, better decide yourself where to have them. I
> pledge insanity in the act.
>
guess where I have learnt that this produces an overflow?
)))

Malcolm McLean <> writes:
> On Feb 16, 6:01Â*pm, Keith Thompson <ks...@mib.org> wrote:
>> There's rarely *any* reason to use strncpy(). Â*It's not a "safer"
>> version of strcpy(); it's a quite different function. Â*It can leave
>> the target buffer without a terminating '\0' (i.e., not a string),
>> or it can pad it with multiple needless '\0' bytes.
>>
> It's designed for databases with fixed fields and non-nul terminated
> strings. The padding zeros aren't unnecessary, because often these
> databases do a quick match or lookup by applying some algorithm to the
> whole field.

Yes, the padding zeros are necessary *if* you're dealing with that
kind of data structure.

I suspect that strncpy() is used incorrectly, under the assumption
that it's a "safer" strcpy(), more often than it's used correctly.
IMHO it shouldn't be in the standard library, at least not with
that name.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 2012-02-16, Stephen Sprunk <> wrote:
> On 16-Feb-12 11:05, nroberts wrote:
>> char const* f(char const* incoming)
>> {
>> static char buf[MAX];
>>
>> strncpy(buf, incoming, strlen(incoming));
>> }
>>
> Assuming this is representative of the actual code, it's clearly wrong
> because strncpy() will overflow buf if strlen(incoming)+1 is greater
> than MAX. This means it is no better than strcpy(buf, incoming).

Nit: it wil overflow if strlen(incoming) is greater than MAX.
It wil not overflow if strlen(incoming) equals MAX.
In that case, it will leave an unterminated string in buf,
but most people wouldn't call that an overflow.

On Feb 16, 5:05*pm, nroberts <roberts.n...@gmail.com> wrote:
> Consider:
>
> char const* f(char const* incoming)
> {
> * static char buf[MAX];
>
> * strncpy(buf, incoming, strlen(incoming));
>
> }
>
> Is there ANY reason to use strncpy like that?

no. Besides all the other problems the function doesn't return
anything and buf[] is inaccessible. I suspect you meant to return
&buf[0].


> *I'm working on a
> project that has such uses all throughout it and before I tell the
> team leader that he's using a basic C function incorrectly I thought
> I'd make sure I'm right.

On Feb 16, 10:20*pm, Keith Thompson <ks...@mib.org> wrote:
>
> I suspect that strncpy() is used incorrectly, under the assumption
> that it's a "safer" strcpy(), more often than it's used correctly.
> IMHO it shouldn't be in the standard library, at least not with
> that name.
>
You're right.
There's no point providing strncpy() but not functions like hash() and
faststrncmpwithtrailingzeros() to actually use fixed width strings.
--
Malcolm's website
http://www.malcommclean.site11.com/www

On 02/17/2012 07:19 AM, Malcolm McLean wrote:
> On Feb 16, 10:20�pm, Keith Thompson <ks...@mib.org> wrote:
>>
>> I suspect that strncpy() is used incorrectly, under the assumption
>> that it's a "safer" strcpy(), more often than it's used correctly.
>> IMHO it shouldn't be in the standard library, at least not with
>> that name.
>>
> You're right.
> There's no point providing strncpy() but not functions like hash() and
> faststrncmpwithtrailingzeros() to actually use fixed width strings.

What would be the benefits of using faststrncmpwithtrailingzeros()
rather than memcmp() be?
--
James Kuyper

On Feb 17, 3:04*pm, James Kuyper <jameskuy...@verizon.net> wrote:
>
> What would be the benefits of using faststrncmpwithtrailingzeros()
> rather than memcmp() be?
>
That's a point. It documents that you're doing a string compare, but
actually it's the same as memcmp(). On most platforms, it will need
guaranteed integer-aligned fields to be fast, however. That's not
something it's easy to specify in the C standard.
--
Vist my website. Play the Alice in Wonderland Card game
http://www.malcommclean.site11.com/www

On Feb 17, 3:04*pm, James Kuyper <jameskuy...@verizon.net> wrote:
>
> What would be the benefits of using faststrncmpwithtrailingzeros()
> rather than memcmp() be?
>
If you have long fields with mainly short contents, it could also be
faster, since it can terminate at the first pair of nul bytes.

On 02/17/2012 02:22 PM, Malcolm McLean wrote:
> On Feb 17, 3:04�pm, James Kuyper <jameskuy...@verizon.net> wrote:
>>
>> What would be the benefits of using faststrncmpwithtrailingzeros()
>> rather than memcmp() be?
>>
> If you have long fields with mainly short contents, it could also be
> faster, since it can terminate at the first pair of nul bytes.

If you know that the the end of the string will be determined either by
the end of a fixed-length field, or by a terminating null character,
strncmp(). If you want to check the entire length of the fixed length
field, regardless of null terminators, memcmp() would do. I don't think
that there's sufficient need for a function whose behavior falls
between those two extremes, to make it a standard library function.
--
James Kuyper