Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #86454 > unrolled thread
| Started by | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| First post | 2022-09-21 10:04 +0000 |
| Last post | 2022-09-22 21:03 -0500 |
| Articles | 20 on this page of 90 — 16 participants |
Back to article view | Back to comp.lang.c++
Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-21 10:04 +0000
Re: Never use strncpy! "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-09-21 15:06 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 15:24 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 15:30 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 19:20 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 19:33 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-21 23:14 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-22 04:40 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 08:56 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-22 12:02 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-23 13:23 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 13:49 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-23 15:25 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 16:03 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-23 14:34 +0000
Re: Never use strncpy! Michael S <already5chosen@yahoo.com> - 2022-09-23 08:19 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-23 17:57 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-23 18:36 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 16:22 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 16:25 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 17:09 +0200
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 17:14 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-26 17:34 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 07:53 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-26 10:21 +0200
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 08:34 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-26 13:39 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-26 17:47 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-27 14:17 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-27 18:07 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-27 12:42 -0700
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-28 09:32 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-28 13:34 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-28 21:11 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-01 06:26 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-10-01 17:01 +0000
Re: Never use strncpy! Michael S <already5chosen@yahoo.com> - 2022-10-02 15:32 -0700
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-10-03 14:01 +0000
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-03 13:49 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 12:46 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 04:14 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:43 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:48 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 04:53 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 19:58 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-10-03 08:27 +0200
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-03 13:49 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-04 10:53 -0700
Re: Never use strncpy! "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-10-02 12:44 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 05:59 +0000
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 09:32 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 15:42 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 18:10 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 16:19 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-21 18:27 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-23 14:47 +0000
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-21 16:12 +0000
Re: Never use strncpy! Philipp Klaus Krause <pkk@spth.de> - 2022-09-23 19:52 +0200
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-24 16:25 +0200
Re: Never use strncpy! scott@slp53.sl.home (Scott Lurndal) - 2022-09-21 14:00 +0000
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:03 +0000
Re: Never use strncpy! Philipp Klaus Krause <pkk@spth.de> - 2022-09-23 19:50 +0200
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-26 07:54 +0000
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-21 15:56 +0100
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-21 15:36 +0000
Re: Never use strncpy! Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> - 2022-09-21 08:59 -0700
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-21 13:23 -0700
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-21 21:49 +0100
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-21 19:18 -0400
Re: Never use strncpy! Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-22 00:39 +0100
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-21 20:45 -0400
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 18:00 -0700
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 17:55 -0700
Re: Never use strncpy! Juha Nieminen <nospam@thanks.invalid> - 2022-09-22 06:09 +0000
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-22 11:44 -0700
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-22 23:33 -0400
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-22 19:00 -0700
Re: Never use strncpy! Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-09-22 19:04 -0700
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-22 22:49 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 11:38 +0200
Re: Never use strncpy! Muttley@dastardlyhq.com - 2022-09-24 09:43 +0000
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 11:59 +0200
Re: Never use strncpy! Richard Damon <Richard@Damon-Family.org> - 2022-09-24 06:27 -0400
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-24 11:53 -0700
Re: Never use strncpy! Bonita Montero <Bonita.Montero@gmail.com> - 2022-09-24 20:58 +0200
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-21 16:01 -0700
Re: Never use strncpy! David Brown <david.brown@hesbynett.no> - 2022-09-22 09:37 +0200
Re: Never use strncpy! Manfred <noname@add.invalid> - 2022-10-01 01:24 +0200
Re: Never use strncpy! Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-30 16:43 -0700
Re: Never use strncpy! Lynn McGuire <lynnmcguire5@gmail.com> - 2022-09-22 21:03 -0500
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-22 06:03 +0000 |
| Message-ID | <tggtqq$10rd$2@gioia.aioe.org> |
| In reply to | #86458 |
Scott Lurndal <scott@slp53.sl.home> wrote: > Juha Nieminen <nospam@thanks.invalid> writes: >>Well, *almost* never, at least. >> >>I always thought that std::strncpy() works exactly like std::strcpy(), >>except that it stops early if the specified count is reached. Turns out >>that I was gravely mistaken: > > I've always used memcpy. I've very seldom used any str* function > other than strlen and once in a blue moon, strtok. I use snprintf > in place of strcat, for instance. memcpy requires you to know the length of the string in advance, which is often not necessary, and would require traversing the string twice in order to copy it. (Why traverse it twice? You can copy it while traversing it for the first time!)
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2022-09-23 19:50 +0200 |
| Message-ID | <tgkrkk$qc1$1@solani.org> |
| In reply to | #86482 |
Am 22.09.22 um 08:03 schrieb Juha Nieminen: > Scott Lurndal <scott@slp53.sl.home> wrote: >> Juha Nieminen <nospam@thanks.invalid> writes: >>> Well, *almost* never, at least. >>> >>> I always thought that std::strncpy() works exactly like std::strcpy(), >>> except that it stops early if the specified count is reached. Turns out >>> that I was gravely mistaken: >> >> I've always used memcpy. I've very seldom used any str* function >> other than strlen and once in a blue moon, strtok. I use snprintf >> in place of strcat, for instance. > > memcpy requires you to know the length of the string in advance, which > is often not necessary, and would require traversing the string twice > in order to copy it. (Why traverse it twice? You can copy it while > traversing it for the first time!) How about using memccpy? It is in C23, don't know about C++.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-26 07:54 +0000 |
| Message-ID | <tgrlsa$1ctg$2@gioia.aioe.org> |
| In reply to | #86541 |
Philipp Klaus Krause <pkk@spth.de> wrote: > Am 22.09.22 um 08:03 schrieb Juha Nieminen: >> Scott Lurndal <scott@slp53.sl.home> wrote: >>> Juha Nieminen <nospam@thanks.invalid> writes: >>>> Well, *almost* never, at least. >>>> >>>> I always thought that std::strncpy() works exactly like std::strcpy(), >>>> except that it stops early if the specified count is reached. Turns out >>>> that I was gravely mistaken: >>> >>> I've always used memcpy. I've very seldom used any str* function >>> other than strlen and once in a blue moon, strtok. I use snprintf >>> in place of strcat, for instance. >> >> memcpy requires you to know the length of the string in advance, which >> is often not necessary, and would require traversing the string twice >> in order to copy it. (Why traverse it twice? You can copy it while >> traversing it for the first time!) > > How about using memccpy? It is in C23, don't know about C++. That sounds like it would be the exact tool for the job.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-21 15:56 +0100 |
| Message-ID | <87mtas22ty.fsf@bsb.me.uk> |
| In reply to | #86454 |
Juha Nieminen <nospam@thanks.invalid> writes: > Well, *almost* never, at least. > > I always thought that std::strncpy() works exactly like std::strcpy(), > except that it stops early if the specified count is reached. Turns out > that I was gravely mistaken: > > "If, after copying the terminating null character from src, count is not > reached, additional null characters are written to dest until the total > of count characters have been written." ... > "If count is reached before the entire string src was copied, the > resulting character array is not null-terminated." Yes, a famous oddity that stems from one very specific use in fixed-width Unix data structures (the most common use for a file name in a directory entry that had to be zero filled but need not be zero terminated). > I can't find any standard library (C or C++) function that does that, > so you'll just have to write your own. (Luckily it's trivial to do.) A common trick was to write *dest = 0; strncat(dest, source, N); or even (in an expression context) strncat((*dest = 0, dest), source, N) > Perhaps return to the caller some value telling if the string was > truncated. If your C library includes Annex K there is the rather gruesome strncpy_t function. And there is a very widely available, but non-standard, function called strlcat. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-21 15:36 +0000 |
| Message-ID | <tgfb23$9sg$1@gioia.aioe.org> |
| In reply to | #86454 |
On Wed, 21 Sep 2022 10:04:09 -0000 (UTC) Juha Nieminen <nospam@thanks.invalid> wrote: >Well, *almost* never, at least. > >I always thought that std::strncpy() works exactly like std::strcpy(), >except that it stops early if the specified count is reached. Turns out >that I was gravely mistaken: > >"If, after copying the terminating null character from src, count is not >reached, additional null characters are written to dest until the total >of count characters have been written." > >This means that if you have, let's say, a 1 MB buffer into which you copy >with std::strncpy() lots and lots of strings, the vast majority of them >very short, expecting it to be efficient... turns out you'll be writing >1 MB worth of data every single time. Which will make the thing quite >slow if you weren't aware of this. Useful to know. Wonder why they did it that way? Doesn't seem very logical.
[toc] | [prev] | [next] | [standalone]
| From | Frederick Virchanza Gotham <cauldwell.thomas@gmail.com> |
|---|---|
| Date | 2022-09-21 08:59 -0700 |
| Message-ID | <2d6bc3e2-3f57-4b0b-93bd-ec5c391652bfn@googlegroups.com> |
| In reply to | #86454 |
On Wednesday, September 21, 2022 at 11:04:29 AM UTC+1, Juha Nieminen wrote: > "If count is reached before the entire string src was copied, the > resulting character array is not null-terminated." In my last job I programmed cameras with embedded Linux, and I outlawed 'strncpy'. I didn't put it in my own code reviews and I didn't accept code reviews containing it. Very poorly designed.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2022-09-21 13:23 -0700 |
| Message-ID | <tgfrsh$1t9lp$1@dont-email.me> |
| In reply to | #86454 |
On 9/21/2022 3:04 AM, Juha Nieminen wrote: > > I always thought that std::strncpy() works exactly like std::strcpy(), > except that it stops early if the specified count is reached. Turns out > that I was gravely mistaken: > The matter has been explained, explained and over-explained to death already, including here in comp.lang.* newsgroups. It is well-known that `strncpy` has never been intended as a "safe string copying" function. It is a niche function introduced for so called "fixed-width" string support. https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings It has never been intended for use with zero-terminated strings. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-21 21:49 +0100 |
| Message-ID | <87o7v8zc4x.fsf@bsb.me.uk> |
| In reply to | #86471 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes: > On 9/21/2022 3:04 AM, Juha Nieminen wrote: >> I always thought that std::strncpy() works exactly like std::strcpy(), >> except that it stops early if the specified count is reached. Turns out >> that I was gravely mistaken: >> > > The matter has been explained, explained and over-explained to death > already, including here in comp.lang.* newsgroups. It is well-known > that `strncpy` has never been intended as a "safe string copying" > function. It is a niche function introduced for so called > "fixed-width" string support. > > https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings > > It has never been intended for use with zero-terminated strings. Except for the quibble that a null in the source string is respected -- i.e. the destination is considered to be a fixed-width field but not the source. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-09-21 19:18 -0400 |
| Message-ID | <iZMWK.645711$BKL8.558482@fx15.iad> |
| In reply to | #86472 |
On 9/21/22 4:49 PM, Ben Bacarisse wrote: > Andrey Tarasevich <andreytarasevich@hotmail.com> writes: > >> On 9/21/2022 3:04 AM, Juha Nieminen wrote: >>> I always thought that std::strncpy() works exactly like std::strcpy(), >>> except that it stops early if the specified count is reached. Turns out >>> that I was gravely mistaken: >>> >> >> The matter has been explained, explained and over-explained to death >> already, including here in comp.lang.* newsgroups. It is well-known >> that `strncpy` has never been intended as a "safe string copying" >> function. It is a niche function introduced for so called >> "fixed-width" string support. >> >> https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings >> >> It has never been intended for use with zero-terminated strings. > > Except for the quibble that a null in the source string is respected -- > i.e. the destination is considered to be a fixed-width field but not the > source. > Yes, it is to copy a "C String" (Null Terminated) into a fixed width field.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-22 00:39 +0100 |
| Message-ID | <87czboz48n.fsf@bsb.me.uk> |
| In reply to | #86475 |
Richard Damon <Richard@Damon-Family.org> writes: > On 9/21/22 4:49 PM, Ben Bacarisse wrote: >> Andrey Tarasevich <andreytarasevich@hotmail.com> writes: >> >>> On 9/21/2022 3:04 AM, Juha Nieminen wrote: >>>> I always thought that std::strncpy() works exactly like std::strcpy(), >>>> except that it stops early if the specified count is reached. Turns out >>>> that I was gravely mistaken: >>>> >>> >>> The matter has been explained, explained and over-explained to death >>> already, including here in comp.lang.* newsgroups. It is well-known >>> that `strncpy` has never been intended as a "safe string copying" >>> function. It is a niche function introduced for so called >>> "fixed-width" string support. >>> >>> https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings >>> >>> It has never been intended for use with zero-terminated strings. >> Except for the quibble that a null in the source string is respected -- >> i.e. the destination is considered to be a fixed-width field but not the >> source. > > Yes, it is to copy a "C String" (Null Terminated) into a fixed width > field. Again, a quibble: not quite. A null will be respected, but there is no need for the source to be a C string. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-09-21 20:45 -0400 |
| Message-ID | <WeOWK.216100$9Yp5.182042@fx12.iad> |
| In reply to | #86476 |
On 9/21/22 7:39 PM, Ben Bacarisse wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> On 9/21/22 4:49 PM, Ben Bacarisse wrote: >>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes: >>> >>>> On 9/21/2022 3:04 AM, Juha Nieminen wrote: >>>>> I always thought that std::strncpy() works exactly like std::strcpy(), >>>>> except that it stops early if the specified count is reached. Turns out >>>>> that I was gravely mistaken: >>>>> >>>> >>>> The matter has been explained, explained and over-explained to death >>>> already, including here in comp.lang.* newsgroups. It is well-known >>>> that `strncpy` has never been intended as a "safe string copying" >>>> function. It is a niche function introduced for so called >>>> "fixed-width" string support. >>>> >>>> https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings >>>> >>>> It has never been intended for use with zero-terminated strings. >>> Except for the quibble that a null in the source string is respected -- >>> i.e. the destination is considered to be a fixed-width field but not the >>> source. >> >> Yes, it is to copy a "C String" (Null Terminated) into a fixed width >> field. > > Again, a quibble: not quite. A null will be respected, but there is no > need for the source to be a C string. > It may be able to do more, but I suspect the purpose it was designed was for that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-21 18:00 -0700 |
| Message-ID | <87sfkkdy02.fsf@nosuchdomain.example.com> |
| In reply to | #86477 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 9/21/22 7:39 PM, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>
>>> On 9/21/22 4:49 PM, Ben Bacarisse wrote:
>>>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>>>
>>>>> On 9/21/2022 3:04 AM, Juha Nieminen wrote:
>>>>>> I always thought that std::strncpy() works exactly like std::strcpy(),
>>>>>> except that it stops early if the specified count is reached. Turns out
>>>>>> that I was gravely mistaken:
>>>>>>
>>>>>
>>>>> The matter has been explained, explained and over-explained to death
>>>>> already, including here in comp.lang.* newsgroups. It is well-known
>>>>> that `strncpy` has never been intended as a "safe string copying"
>>>>> function. It is a niche function introduced for so called
>>>>> "fixed-width" string support.
>>>>>
>>>>> https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings
>>>>>
>>>>> It has never been intended for use with zero-terminated strings.
>>>> Except for the quibble that a null in the source string is respected --
>>>> i.e. the destination is considered to be a fixed-width field but not the
>>>> source.
>>>
>>> Yes, it is to copy a "C String" (Null Terminated) into a fixed width
>>> field.
>> Again, a quibble: not quite. A null will be respected, but there is
>> no need for the source to be a C string.
>
> It may be able to do more, but I suspect the purpose it was designed
> was for that.
According to the standard's description, the source clearly does not
have to point to a C string -- and strncpy() would work perfectly well
to copy one fixed-sized buffer to another, which is a very plausible use
case if you're working with such a data structure.
char source[5] = "hello"; // no null terminator
char target[5];
strncpy(target, source, sizeof target);
Of course it also works if the source is a pointer to a C string, and
it's explicitly required to deal with the null terminator.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-21 17:55 -0700 |
| Message-ID | <87wn9wdy7d.fsf@nosuchdomain.example.com> |
| In reply to | #86476 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 9/21/22 4:49 PM, Ben Bacarisse wrote:
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>>>
>>>> On 9/21/2022 3:04 AM, Juha Nieminen wrote:
>>>>> I always thought that std::strncpy() works exactly like std::strcpy(),
>>>>> except that it stops early if the specified count is reached. Turns out
>>>>> that I was gravely mistaken:
>>>>>
>>>>
>>>> The matter has been explained, explained and over-explained to death
>>>> already, including here in comp.lang.* newsgroups. It is well-known
>>>> that `strncpy` has never been intended as a "safe string copying"
>>>> function. It is a niche function introduced for so called
>>>> "fixed-width" string support.
>>>>
>>>> https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings
>>>>
>>>> It has never been intended for use with zero-terminated strings.
>>> Except for the quibble that a null in the source string is respected --
>>> i.e. the destination is considered to be a fixed-width field but not the
>>> source.
>>
>> Yes, it is to copy a "C String" (Null Terminated) into a fixed width
>> field.
>
> Again, a quibble: not quite. A null will be respected, but there is no
> need for the source to be a C string.
You're right (and I misstated it in a recent post). The standard (I'll
quote N1570 because I have it open) says:
The strncpy function copies not more than n characters (characters
that follow a null character are not copied) from the array pointed
to by s2 to the array pointed to by s1. If copying takes place
between objects that overlap, the behavior is undefined.
Which means that the source doesn't have to point to a C string.
The Linux Programmer's Manual man page incorrectly suggests that the
source has to be a pointer to a C string:
The strcpy() function copies the string pointed to by src,
including the terminating null byte ('\0'), to the buffer pointed
to by dest.
[...]
The strncpy() function is similar, except that at most n bytes of
src are copied.
The phrase "the string pointed to by src" in the description of strcpy
implies that the behavior is undefined if src doesn't point to a string.
The man page incorrectly implies that same wording applies to strncpy.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-09-22 06:09 +0000 |
| Message-ID | <tggu66$10rd$3@gioia.aioe.org> |
| In reply to | #86475 |
Richard Damon <Richard@damon-family.org> wrote: >> Except for the quibble that a null in the source string is respected -- >> i.e. the destination is considered to be a fixed-width field but not the >> source. >> > > Yes, it is to copy a "C String" (Null Terminated) into a fixed width field. Then it should have been named something entirely different. As it is now it gets extremely easily confused with strcpy(), as if it were a "safer" variant of it, in the same was as strncat() is a "safer" variant of strcat().
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-22 11:44 -0700 |
| Message-ID | <87k05vdza5.fsf@nosuchdomain.example.com> |
| In reply to | #86483 |
Juha Nieminen <nospam@thanks.invalid> writes:
> Richard Damon <Richard@damon-family.org> wrote:
>>> Except for the quibble that a null in the source string is respected --
>>> i.e. the destination is considered to be a fixed-width field but not the
>>> source.
>>>
>>
>> Yes, it is to copy a "C String" (Null Terminated) into a fixed width field.
>
> Then it should have been named something entirely different. As it is now
> it gets extremely easily confused with strcpy(), as if it were a "safer"
> variant of it, in the same was as strncat() is a "safer" variant of
> strcat().
It's already been pointed out that the source argument to strncpy() does
not need to be a pointer to a (null-terminated) string.
And yes, the name is misleading (also already pointed out).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-09-22 23:33 -0400 |
| Message-ID | <yO9XK.166803$elEa.156555@fx09.iad> |
| In reply to | #86483 |
On 9/22/22 2:09 AM, Juha Nieminen wrote: > Richard Damon <Richard@damon-family.org> wrote: >>> Except for the quibble that a null in the source string is respected -- >>> i.e. the destination is considered to be a fixed-width field but not the >>> source. >>> >> >> Yes, it is to copy a "C String" (Null Terminated) into a fixed width field. > > Then it should have been named something entirely different. As it is now > it gets extremely easily confused with strcpy(), as if it were a "safer" > variant of it, in the same was as strncat() is a "safer" variant of > strcat(). Maybe, but it was names LONG ago in the infancy of the language, so that is water under the bridge. One thing to remember, the n versions weren't so much designed as "Safter" versions, but versions for a special purpose. THey may work as safer versions, but I don't think that was major goal.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2022-09-22 19:00 -0700 |
| Message-ID | <tgj3vi$2eble$1@dont-email.me> |
| In reply to | #86472 |
On 9/21/2022 1:49 PM, Ben Bacarisse wrote: > Andrey Tarasevich <andreytarasevich@hotmail.com> writes: > >> On 9/21/2022 3:04 AM, Juha Nieminen wrote: >>> I always thought that std::strncpy() works exactly like std::strcpy(), >>> except that it stops early if the specified count is reached. Turns out >>> that I was gravely mistaken: >>> >> >> The matter has been explained, explained and over-explained to death >> already, including here in comp.lang.* newsgroups. It is well-known >> that `strncpy` has never been intended as a "safe string copying" >> function. It is a niche function introduced for so called >> "fixed-width" string support. >> >> https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings >> >> It has never been intended for use with zero-terminated strings. > > Except for the quibble that a null in the source string is respected -- > i.e. the destination is considered to be a fixed-width field but not the > source. > Yes, by spec, it is a _conversion_ function. Its specific purpose is to convert a zero-terminated source string to a fixed-width target string. In modern usage (under assumption that nobody needs fixed-width strings anymore), this function might still be usable for secure initialization of sensitive data fields, when one wants to make sure that the old string content of the data field is fully erased when the new string is copied in. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2022-09-22 19:04 -0700 |
| Message-ID | <tgj485$2ecmp$1@dont-email.me> |
| In reply to | #86511 |
On 9/22/2022 7:00 PM, Andrey Tarasevich wrote: > On 9/21/2022 1:49 PM, Ben Bacarisse wrote: >> Andrey Tarasevich <andreytarasevich@hotmail.com> writes: >> >>> On 9/21/2022 3:04 AM, Juha Nieminen wrote: >>>> I always thought that std::strncpy() works exactly like std::strcpy(), >>>> except that it stops early if the specified count is reached. Turns out >>>> that I was gravely mistaken: >>>> >>> >>> The matter has been explained, explained and over-explained to death >>> already, including here in comp.lang.* newsgroups. It is well-known >>> that `strncpy` has never been intended as a "safe string copying" >>> function. It is a niche function introduced for so called >>> "fixed-width" string support. >>> >>> https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings >>> >>> >>> It has never been intended for use with zero-terminated strings. >> >> Except for the quibble that a null in the source string is respected -- >> i.e. the destination is considered to be a fixed-width field but not the >> source. >> > > Yes, by spec, it is a _conversion_ function. Its specific purpose is to > convert a zero-terminated source string to a fixed-width target string. > ... and yes, Keith Thompson makes a good point that the source does not have to be a zero-terminated string. I.e. it can also be used for fixed-width string copying. One can probably argue that it might be more efficient than plain `memcpy`, since `memcpy` would copy the original zeroes with a memory-to-memory operation, while `strncpy` would fill the tail portion of the string with "its own" zeros instead. -- Best regards, Andrey
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-22 22:49 -0700 |
| Message-ID | <87bkr6ej29.fsf@nosuchdomain.example.com> |
| In reply to | #86513 |
Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
[...]
> ... and yes, Keith Thompson makes a good point that the source does
> not have to be a zero-terminated string. I.e. it can also be used for
> fixed-width string copying.
To be fair, it was Ben Bacarisse who pointed this out -- *after* I had
incorrectly stated (based on faulty man page) that the source has to be
a pointer to a null-terminated string.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-24 11:38 +0200 |
| Message-ID | <tgmj5q$2uq23$1@dont-email.me> |
| In reply to | #86471 |
Am 21.09.2022 um 22:23 schrieb Andrey Tarasevich: > On 9/21/2022 3:04 AM, Juha Nieminen wrote: >> >> I always thought that std::strncpy() works exactly like std::strcpy(), >> except that it stops early if the specified count is reached. Turns out >> that I was gravely mistaken: >> > > The matter has been explained, explained and over-explained to death > already, including here in comp.lang.* newsgroups. It is well-known that > `strncpy` has never been intended as a "safe string copying" function. > It is a niche function introduced for so called "fixed-width" string > support. > > https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings > > It has never been intended for use with zero-terminated strings. > The problem with that is that you can't pass a string copied like that reliably to any C-API that requires a null-terminated string. It would have been better if strncpy() would always return a null-terminated string, thereby making the last character zero if necessary. For me this API rather looks mostly useless.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c++
csiph-web