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 1 of 3  [1] 2 3  Next page →

#17454 — strncpy and 'n'

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.

[toc] | [next] | [standalone]

#17460

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

> 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?

 If you want to avoid havig the '\0' copied from the incoming text,
and risk overrunning buf, there could be a point. But apart from that, no. 

 I would rather use strncpy like this:

 strncpy (buf, incoming, MAX);
 buf[MAX] = 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.

 Submit some code to www.thedailywtf.com :)


 

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

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

#17463

On 16.02.2012 18:57, Anders Wegge Keller wrote:
> nroberts<roberts.noah@gmail.com>  writes:
>
>> 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?
>
>   If you want to avoid havig the '\0' copied from the incoming text,
> and risk overrunning buf, there could be a point. But apart from that, no.
>
>   I would rather use strncpy like this:
>
>   strncpy (buf, incoming, MAX);
>   buf[MAX] = 0;

buffer overflow !!!    :o)

>
>>   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.
>
>   Submit some code to www.thedailywtf.com :)
>
>
>
>

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

#17464

"A. K." <akk@nospam.org> writes:

> On 16.02.2012 18:57, Anders Wegge Keller wrote:

>>   buf[MAX] = 0;
 
 buffer overflow !!!    :o)

 If you got to have them, better decide yourself where to have them. I
pledge insanity in the act.

-- 
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

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

#17471

On 16.02.2012 19:34, Anders Wegge Keller wrote:
> "A. K."<akk@nospam.org>  writes:
>
>> On 16.02.2012 18:57, Anders Wegge Keller wrote:
>
>>>    buf[MAX] = 0;
>
>   buffer overflow !!!    :o)
>
>   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?
:o)))

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

#17461

nroberts <roberts.noah@gmail.com> writes:
> 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.

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.

For that particular call, if strlen(incoming) is 10, for example,
it will only copy 10 bytes; it will not copy the terminating '\0'.
If that's what you want (either buf doesn't need to be a string, or
some other code supplies the '\0'), then memcpy() makes more sense.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

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

#17466

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.

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

#17480

Malcolm McLean <malcolm.mclean5@btinternet.com> 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-u@mib.org  <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"

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

#17508

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

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

#17513

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

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

#17527

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

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

#17528

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.

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

#17529

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

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

#17560

On Feb 17, 7:40 pm, James Kuyper <jameskuy...@verizon.net> wrote:
>
> 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.
>
The main issue is usually that reading chars byte by byte is slow,
reading words is fast.

So if fields are guaranteed to be memory aligned, and a whole number
of words, a comparison will be certainly four times and often many
more times as fast as a byte by byte compare of unaligned strings of
arbitrary length. Aligned fields of whole word size are quite easy to
achieve at a low level, but difficult to specify in ANSI standard C.

Malcolm's website
http://www.malcolmmclean.site11.com/www

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

#17619

In article <lnvcn6fyi2.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@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 is a safer version of 'strcpy'.  There is the issue of what to do if
the full copy can't be done, but that's program logic and the library
function can't read people's minds.  Even if the program just calls
'abort', that's a huge improvement.

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

#17623

jgk@panix.com (Joe keane) writes:
> In article <lnvcn6fyi2.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@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 is a safer version of 'strcpy'.  There is the issue of what to do if
> the full copy can't be done, but that's program logic and the library
> function can't read people's minds.  Even if the program just calls
> 'abort', that's a huge improvement.

Did you not read my description of what strncpy actually does, or do you
disagree with it?

strncat is a "safer" version of strcat.  It takes an extra argument
"n" that specifies the maximum number of characters to be copied.  If
the source is longer than n characters, it appends just n characters.
It properly zero-terminates the destination in all cases.

strncpy *looks* like it should be to strcpy as strncat is to strcat,
but it isn't.  If the source string is shorter than n characters,
it will pad the destination with multiple null characters, something
that strcpy never does.  If the source string is longer than n
characters, it will leave the destination unterminated (i.e.,
not a string).

If it had been defined something like this:

    char *better_strncpy(char *dest, const char *src, size_t n) {
        dest[0] = '\0';
        return strncat(dest, src, n);
    }

then it would be reasonable to call it a "safer" version of strcpy.

(It's possible I have an off-by-one error in the above code;
I haven't taken the time to check.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

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

#17704

In article <lnboouef7m.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>strncpy *looks* like it should be to strcpy as strncat is to strcat,
>but it isn't.

Well there is a number of options.

a) should it make sure there is a zero terminator
b) maybe you want to clear everything that isn't copied
c) does it handle overlapping copies

Do i think it's slightly stupid that they don't match?  A little bit.
But one can imagine that good choices were made, and that consistency is
sometimes negative.

Why does 'puts' add a newline, and 'fputs' doesn't?
Why does 'fgets' take a size argument, and 'gets' doesn't?
Why can i use the same format for float/double in 'fprintf', but not in
'fscanf'?
Why is it that multiply long and long gives long, but short and short
gives int?
Why can i use a bitfield in a struct, but not as a local variable?
Why is it that 'int' means signed, but 'char' can be either one?

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

#17706

jgk@panix.com (Joe keane) writes:
> In article <lnboouef7m.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>strncpy *looks* like it should be to strcpy as strncat is to strcat,
>>but it isn't.
>
> Well there is a number of options.
>
> a) should it make sure there is a zero terminator
> b) maybe you want to clear everything that isn't copied
> c) does it handle overlapping copies
>
> Do i think it's slightly stupid that they don't match?  A little bit.
> But one can imagine that good choices were made, and that consistency is
> sometimes negative.

The point is that strncpy is a very different function from strcpy.
It is not intended to work with a *string* in the target array;
it works with a specialized data structure (used to store file
names in very early Unix systems).

> Why does 'puts' add a newline, and 'fputs' doesn't?
> Why does 'fgets' take a size argument, and 'gets' doesn't?
> Why can i use the same format for float/double in 'fprintf', but not in
> 'fscanf'?
> Why is it that multiply long and long gives long, but short and short
> gives int?
> Why can i use a bitfield in a struct, but not as a local variable?
> Why is it that 'int' means signed, but 'char' can be either one?

There are answers for most of these questions.  For others,
it's certainly true that the C standard library is not entirelyi
consistent.  But I don't think any of them are particularly relevant
to strncpy.

I think you're understating the differences between strcpy and
strncpy.  The strncpy function is radically different from strcpy,
and there are very few legitimate uses for it.  On the other hand,
the deceptive name has led many C programmers to use it incorrectly,
and I strongly suspect that it's  used incorrectly far more often
than it's used correctly.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

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

#17858

On Mon, 2012-02-20, Keith Thompson wrote:
> jgk@panix.com (Joe keane) writes:
>> In article <lnboouef7m.fsf@nuthaus.mib.org>,
>> Keith Thompson  <kst-u@mib.org> wrote:
>>>strncpy *looks* like it should be to strcpy as strncat is to strcat,
>>>but it isn't.
>>
>> Well there is a number of options.
>>
>> a) should it make sure there is a zero terminator
>> b) maybe you want to clear everything that isn't copied
>> c) does it handle overlapping copies
>>
>> Do i think it's slightly stupid that they don't match?  A little bit.
>> But one can imagine that good choices were made, and that consistency is
>> sometimes negative.
>
> The point is that strncpy is a very different function from strcpy.
> It is not intended to work with a *string* in the target array;
> it works with a specialized data structure (used to store file
> names in very early Unix systems).

Malcolm McLean wrote something similar upthread. Do you have any
references for this?

It would explain the function's weird semantics, but I haven't seen
anything before which says this is its background.  (There's also
wcsncpy() for wchar_t -- that one is certainly newer, and useless in
the data structures you mention.)

...
> I think you're understating the differences between strcpy and
> strncpy.  The strncpy function is radically different from strcpy,
> and there are very few legitimate uses for it.  On the other hand,
> the deceptive name has led many C programmers to use it incorrectly,
> and I strongly suspect that it's  used incorrectly far more often
> than it's used correctly.

The static analysis tool we use at work screams bloody murder every
time I use strcpy() and tells me to use strncpy() instead. Argh ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#17860

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Mon, 2012-02-20, Keith Thompson wrote:
[...]
>> The point is that strncpy is a very different function from strcpy.
>> It is not intended to work with a *string* in the target array;
>> it works with a specialized data structure (used to store file
>> names in very early Unix systems).
>
> Malcolm McLean wrote something similar upthread. Do you have any
> references for this?
>
> It would explain the function's weird semantics, but I haven't seen
> anything before which says this is its background.  (There's also
> wcsncpy() for wchar_t -- that one is certainly newer, and useless in
> the data structures you mention.)

I don't have any definitive references, but there's at
least been plenty of speculation to that effect, for example
<http://stackoverflow.com/a/1454071/827263>.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web