Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #17454 > unrolled thread

strncpy and 'n'

Back to article view | Back to comp.lang.c

Contents

  strncpy and 'n' nroberts <roberts.noah@gmail.com> - 2012-02-16 09:05 -0800
    Re: strncpy and 'n' Anders Wegge Keller <wegge@wegge.dk> - 2012-02-16 18:57 +0100
      Re: strncpy and 'n' "A. K." <akk@nospam.org> - 2012-02-16 19:27 +0100
        Re: strncpy and 'n' Anders Wegge Keller <wegge@wegge.dk> - 2012-02-16 19:34 +0100
          Re: strncpy and 'n' "A. K." <akk@nospam.org> - 2012-02-16 20:58 +0100
    Re: strncpy and 'n' Keith Thompson <kst-u@mib.org> - 2012-02-16 10:01 -0800
      Re: strncpy and 'n' Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-16 11:10 -0800
        Re: strncpy and 'n' Keith Thompson <kst-u@mib.org> - 2012-02-16 14:20 -0800
          Re: strncpy and 'n' Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-17 04:19 -0800
            Re: strncpy and 'n' James Kuyper <jameskuyper@verizon.net> - 2012-02-17 10:04 -0500
              Re: strncpy and 'n' Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-17 10:27 -0800
              Re: strncpy and 'n' Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-17 11:22 -0800
                Re: strncpy and 'n' James Kuyper <jameskuyper@verizon.net> - 2012-02-17 14:40 -0500
                  Re: strncpy and 'n' Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-18 02:17 -0800
      Re: strncpy and 'n' jgk@panix.com (Joe keane) - 2012-02-19 20:04 +0000
        Re: strncpy and 'n' Keith Thompson <kst-u@mib.org> - 2012-02-19 12:33 -0800
          Re: strncpy and 'n' jgk@panix.com (Joe keane) - 2012-02-20 21:25 +0000
            Re: strncpy and 'n' Keith Thompson <kst-u@mib.org> - 2012-02-20 14:46 -0800
              Re: strncpy and 'n' Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-23 23:13 +0000
                Re: strncpy and 'n' Keith Thompson <kst-u@mib.org> - 2012-02-23 16:20 -0800
                Re: strncpy and 'n' Philip Lantz <prl@canterey.us> - 2012-02-25 00:26 -0800
                Re: strncpy and 'n' pacman@kosh.dhis.org (Alan Curry) - 2012-02-26 01:34 +0000
                  Re: strncpy and 'n' Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-28 22:46 +0000
                    Re: strncpy and 'n' jgk@panix.com (Joe keane) - 2012-03-01 00:03 +0000
                      Re: strncpy and 'n' Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-03-01 12:03 +0000
            Re: strncpy and 'n' James Kuyper <jameskuyper@verizon.net> - 2012-02-20 17:51 -0500
          Re: strncpy and 'n' Shao Miller <sha0.miller@gmail.com> - 2012-02-20 18:14 -0500
            Re: strncpy and 'n' pete <pfiland@mindspring.com> - 2012-02-20 23:16 -0500
              Re: strncpy and 'n' Shao Miller <sha0.miller@gmail.com> - 2012-02-25 01:51 -0500
                Re: strncpy and 'n' pete <pfiland@mindspring.com> - 2012-02-25 10:34 -0500
          Re: strncpy and 'n' Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-02-20 19:09 -0500
            Re: strncpy and 'n' Keith Thompson <kst-u@mib.org> - 2012-02-20 16:46 -0800
              Re: strncpy and 'n' Rich Webb <bbew.ar@mapson.nozirev.ten> - 2012-02-20 20:48 -0500
            Re: strncpy and 'n' Shao Miller <sha0.miller@gmail.com> - 2012-02-20 19:46 -0500
          Re: strncpy and 'n' jgk@panix.com (Joe keane) - 2012-02-21 21:46 +0000
            Re: strncpy and 'n' James Kuyper <jameskuyper@verizon.net> - 2012-02-21 17:15 -0500
            Re: strncpy and 'n' Keith Thompson <kst-u@mib.org> - 2012-02-21 14:29 -0800
              Re: strncpy and 'n' Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-22 01:15 -0800
              Re: strncpy and 'n' jgk@panix.com (Joe keane) - 2012-02-23 00:02 +0000
                Re: strncpy and 'n' Keith Thompson <kst-u@mib.org> - 2012-02-22 17:02 -0800
    Re: strncpy and 'n' Markus Schaub <usenet@markus-schaub.de> - 2012-02-16 18:53 +0000
    Re: strncpy and 'n' lawrence.jones@siemens.com - 2012-02-16 13:25 -0500
    Re: strncpy and 'n' blp@cs.stanford.edu (Ben Pfaff) - 2012-02-16 11:18 -0800
    Re: strncpy and 'n' Stephen Sprunk <stephen@sprunk.org> - 2012-02-16 13:29 -0600
      Re: strncpy and 'n' Ike Naar <ike@iceland.freeshell.org> - 2012-02-16 22:45 +0000
    Re: strncpy and 'n' ImpalerCore <jadill33@gmail.com> - 2012-02-16 11:32 -0800
    Re: strncpy and 'n' Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 00:50 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#17465

nroberts schrieb:
> 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.

He has probably heard that strcpy() is bad and that he should use
strncpy().

Markus

[toc] | [prev] | [next] | [standalone]

#17467

nroberts <roberts.noah@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?

Maybe, but almost certainly not.  If the incoming string is longer than
MAX bytes, you get a buffer overflow, which is very bad.  If it happens
to be exactly MAX characters long, you get an unterminated string in
buf, which is bad if the following code (you don't show any, but I
presume there is some or the function is completely pointless) expects
to treat it as a string.  And if the incoming string is less than MAX
bytes, since the code doesn't copy the null byte, you get whatever is
leftover in buf tacked on to the end.  (buf is initialized to all null
bytes, but since it's static, that only happens once, not on each call.)
-- 
Larry Jones

Oh yeah?  You just wait! -- Calvin

[toc] | [prev] | [next] | [standalone]

#17468

nroberts <roberts.noah@gmail.com> writes:

> char const* f(char const* incoming)
> {
>   static char buf[MAX];
>
>   strncpy(buf, incoming, strlen(incoming));
> }
>
> Is there ANY reason to use strncpy like that?  

It looks very odd.  I think it would be equivalent code if you
replaced "strncpy" by "memcpy" here.

The behavior here make sense for the first call to the function,
if strlen(incoming) < MAX, but it will be strange on subsequent
calls.
-- 
"The fact that there is a holy war doesn't mean that one of the sides
 doesn't suck - usually both do..."
--Alexander Viro

[toc] | [prev] | [next] | [standalone]

#17469

On 16-Feb-12 11:05, nroberts 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.

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).

The correct way to write this would be:

char const* f(char const* incoming)
{
  static char buf[MAX];

  strncpy(buf, incoming, MAX);
}

Unlike the above code, this guarantees the copy will not overflow buf.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#17483

On 2012-02-16, Stephen Sprunk <stephen@sprunk.org> 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.

[toc] | [prev] | [next] | [standalone]

#17470

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.

[toc] | [prev] | [next] | [standalone]

#17503

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.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web