Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > strncpy and 'n'

Reply
Thread Tools

strncpy and 'n'

 
 
ImpalerCore
Guest
Posts: n/a
 
      02-16-2012
On Feb 16, 12:05*pm, nroberts <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
A. K.
Guest
Posts: n/a
 
      02-16-2012
On 16.02.2012 19:34, Anders Wegge Keller wrote:
> "A. K."<(E-Mail Removed)> 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?
)))
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-16-2012
Malcolm McLean <(E-Mail Removed)> writes:
> On Feb 16, 6:01*pm, Keith Thompson <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Ike Naar
Guest
Posts: n/a
 
      02-16-2012
On 2012-02-16, Stephen Sprunk <(E-Mail Removed)> 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.
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      02-17-2012
On Feb 16, 5:05*pm, nroberts <(E-Mail Removed)> 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.


 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      02-17-2012
On Feb 16, 10:20*pm, Keith Thompson <(E-Mail Removed)> 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


 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-17-2012
On 02/17/2012 07:19 AM, Malcolm McLean wrote:
> On Feb 16, 10:20�pm, Keith Thompson <(E-Mail Removed)> 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
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      02-17-2012
On Feb 17, 3:04*pm, James Kuyper <(E-Mail Removed)> 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

 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      02-17-2012
On Feb 17, 3:04*pm, James Kuyper <(E-Mail Removed)> 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.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-17-2012
On 02/17/2012 02:22 PM, Malcolm McLean wrote:
> On Feb 17, 3:04�pm, James Kuyper <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
strncpy copying beyond max length atapi103@gmail.com C++ 4 02-01-2005 01:32 PM
the minimum size when using strncpy(...) Simon C++ 3 09-06-2004 01:03 PM
strncpy() and null terminated strings Barry C Programming 4 04-08-2004 05:25 PM
Code Review: strncpy Vijay Kumar R Zanvar C Programming 30 01-19-2004 04:39 PM
Re: bizzare strncpy() sumit.sharma@wipro.com C Programming 4 07-09-2003 01:14 PM



Advertisments