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 | 10 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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-09-24 09:43 +0000 |
| Message-ID | <tgmjgu$12ak$1@gioia.aioe.org> |
| In reply to | #86548 |
On Sat, 24 Sep 2022 11:38:28 +0200 Bonita Montero <Bonita.Montero@gmail.com> wrote: >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. > The C strings API is also inconsistent because snprintf() always adds a terminating null whether the arguments fit into the string or not.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-09-24 11:59 +0200 |
| Message-ID | <tgmkd2$2uth4$1@dont-email.me> |
| In reply to | #86549 |
Am 24.09.2022 um 11:43 schrieb Muttley@dastardlyhq.com: > On Sat, 24 Sep 2022 11:38:28 +0200 > Bonita Montero <Bonita.Montero@gmail.com> wrote: >> 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. >> > > The C strings API is also inconsistent because snprintf() always adds > a terminating null whether the arguments fit into the string or not. > I don't consider this inconsistent because one API is unusable, thereby almost non-existing.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-09-24 06:27 -0400 |
| Message-ID | <BYAXK.193710$elEa.118501@fx09.iad> |
| In reply to | #86548 |
On 9/24/22 5:38 AM, Bonita Montero wrote: > 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. > > And that is because strncpy wasn't intended to create a "C-API" string, but to fill a char[N] field in a struct. There were many spots those existed without a required terminating NULL.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-24 11:53 -0700 |
| Message-ID | <871qs0eh9m.fsf@nosuchdomain.example.com> |
| In reply to | #86551 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> And that is because strncpy wasn't intended to create a "C-API"
> string, but to fill a char[N] field in a struct.
>
> There were many spots those existed without a required terminating NULL.
NUL, null, null character, or '\0', not NULL (which is a null pointer
constant).
--
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 20:58 +0200 |
| Message-ID | <tgnk0c$31san$1@dont-email.me> |
| In reply to | #86566 |
Am 24.09.2022 um 20:53 schrieb Keith Thompson: > Richard Damon <Richard@Damon-Family.org> writes: > [...] >> And that is because strncpy wasn't intended to create a "C-API" >> string, but to fill a char[N] field in a struct. >> >> There were many spots those existed without a required terminating NULL. > > NUL, null, null character, or '\0', not NULL (which is a null pointer > constant). > I woudln't have understood Richard without your help.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-21 16:01 -0700 |
| Message-ID | <874jx0fi2w.fsf@nosuchdomain.example.com> |
| 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."
>
> 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.
>
> It's just better to do your own custom version of strncpy() that does
> what strncpy() should be doing, ie. just stop once the source string
> ends.
>
> 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.)
>
> And while you are at it, you might also want to fix this little problem:
>
> "If count is reached before the entire string src was copied, the
> resulting character array is not null-terminated."
>
> Perhaps return to the caller some value telling if the string was
> truncated.
(Replying in part to things that have been said in other posts in this
thread.)
strncpy() is not poorly designed. It's quite reasonably designed for
the niche purpose for which it was intended, where the source is an
ordinary null-terminated string and the target, an N-byte character
array, hold a sequence of M significant non-null characters followed by
exactly N-M null characters.
It is poorly *named*. The name implies that, as strncat is a "safer"
strcat, strncpy is a "safer" strcpy. Both strncat and strncpy let you
specify the size of the target array, avoiding writing past the end of
it, but strncpy treats its target as null-terminated string.
I wrote about strncpy here (a lot of what I write has been covered in
this thread):
http://the-flat-trantor-society.blogspot.com/2012/03/no-strncpy-is-not-safer-strcpy.html
Of course this is comp.lang.c++, so you should usually be using
std::string, but sometimes you do need to deal with C-style strings.
It's unlikely (but still possible), that strncpy() might be the right
tool for the job. If it is, thoroughly comment the code so that the
next person who maintains it doesn't break your assumptions.
A digression: Quietly truncating the output, as strncpy and strncat do,
is not always "safer". Sometimes it's exactly what you want, for
example if you're printing data in fixed-width columns and it's going to
be obvious that something has been truncated. Sometimes silent
truncation can be worse than terminating the program, for example if a
command string "rm -rf $HOME/tmpdir" is quietly truncated to
"rm -rf $HOME/". If your code handles errors, always think about what
that error handling will actually do.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-22 09:37 +0200 |
| Message-ID | <tgh3ci$2348e$1@dont-email.me> |
| In reply to | #86474 |
On 22/09/2022 01:01, Keith Thompson wrote: > If your code handles errors, always think about what > that error handling will actually do. > That's good general advice for all programming - and something many people don't consider deeply enough. Add to it that your error handling code must be tested as well as the rest of your code. I've seen several cases in practice where poor and untested error handling code turned a glitch into a disaster. (I agree with everything in the rest of your post - it's just that your final sentence looked so good as a "tip of the day" !)
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2022-10-01 01:24 +0200 |
| Message-ID | <th7tqs$829$1@gioia.aioe.org> |
| In reply to | #86474 |
On 9/22/2022 1:01 AM, Keith Thompson wrote: > Juha Nieminen <nospam@thanks.invalid> writes: >> Well, *almost* never, at least. >> [...] > > strncpy() is not poorly designed. [...] > > It is poorly *named*. Agreed. The name implies that, as strncat is a "safer" > strcat, strncpy is a "safer" strcpy. Both strncat and strncpy let you > specify the size of the target array, avoiding writing past the end of > it, but strncpy treats its target as null-terminated string. > (likely typo, sounds like this last bit has been gotten backwards)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-30 16:43 -0700 |
| Message-ID | <87wn9kl980.fsf@nosuchdomain.example.com> |
| In reply to | #86744 |
Manfred <noname@add.invalid> writes:
> On 9/22/2022 1:01 AM, Keith Thompson wrote:
>> Juha Nieminen <nospam@thanks.invalid> writes:
>>> Well, *almost* never, at least.
>>>
> [...]
>> strncpy() is not poorly designed.
> [...]
>> It is poorly *named*.
>
> Agreed.
>
> The name implies that, as strncat is a "safer"
>> strcat, strncpy is a "safer" strcpy. Both strncat and strncpy let you
>> specify the size of the target array, avoiding writing past the end of
>> it, but strncpy treats its target as null-terminated string.
>>
> (likely typo, sounds like this last bit has been gotten backwards)
Yes, thank you. strncat() treats its target (but not its source) as a
null-terminated string, both before and after copying. strncpy() does
not.
--
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 | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2022-09-22 21:03 -0500 |
| Message-ID | <tgj467$uou$1@gioia.aioe.org> |
| In reply to | #86454 |
On 9/21/2022 5:04 AM, Juha Nieminen 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. > > It's just better to do your own custom version of strncpy() that does > what strncpy() should be doing, ie. just stop once the source string > ends. > > 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.) > > And while you are at it, you might also want to fix this little problem: > > "If count is reached before the entire string src was copied, the > resulting character array is not null-terminated." > > Perhaps return to the caller some value telling if the string was > truncated. Thanks for helping me to better understand strncpy. Of course, we use it extensively. Although, we use the "safe" version strncpy_s about half the time, 62 out of 125 uses. Lynn
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c++
csiph-web