Richard Heathfield <rjh@see.sig.invalid> writes:
> Keith Thompson said:
> <snip>
>
>> People tend not to agree with Richard Heathfield when he's right.
>
> Yeah, I noticed that too.
>
> Unfortunately, they don't agree with me when I'm wrong, either. If they
> did, life would be so much simpler.

Argh! What I meant was

People tend not to *disagree* with Richard Heathfield when he's
right.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On Tuesday 06 Nov 2007 3:26 pm Keith Thompson <kst-u@mib.org> wrote in
article <lnprynu26v.fsf@nuthaus.mib.org>:

> Richard Heathfield <rjh@see.sig.invalid> writes:
>> Keith Thompson said:
>> <snip>
>>
>>> People tend not to agree with Richard Heathfield when he's right.
>>
>> Yeah, I noticed that too.
>>
>> Unfortunately, they don't agree with me when I'm wrong, either. If
>> they did, life would be so much simpler.
>
> Argh! What I meant was
>
> People tend not to *disagree* with Richard Heathfield when he's
> right.

Wonder how Richard will respond to this one now?

Perhaps replace the word "agree" above with "disagree"?

Keith Thompson said:

<snip>

> Argh! What I meant was
>
> People tend not to *disagree* with Richard Heathfield when he's
> right.

Oh! :-) Well, that's partly true, but there are plenty of counter-examples
right here in this newsgroup - people who continue to believe I'm wrong,
long after I've demonstrated otherwise.

Name names? What's the point? They know who I mean.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Tobin said:

> In article <1194297184.671793.270610@q3g2000prf.googlegroups. com>,
> William Hughes <wpihughes@hotmail.com> wrote:
>
>>How many legs does a horse have if you call a tail
>>a leg? Four, calling a tail a leg does not make a tail
>>a leg.
>
> It makes "leg" refer to tails as well as legs, so that the statement
> "a horse has five legs" becomes true.
>
> Language is mutable, even if horses aren't.

If you want to be mocked by a six-year-old, telling him or her that a horse
has five legs is a great way to start.

The statement "a horse has five legs" is false, at least for the
overwhelming majority of horses. (I know of no counter-examples.)

Calling a tail a leg does not make "leg" refer to tails as well as legs
except in the mind of the caller and those he can persuade to agree.

Language may well be mutable, but mute it too far and you risk being
misunderstood.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

user923005 wrote:
> On Nov 5, 1:53 pm, jacob navia <ja...@nospam.com> wrote:

[...]

>> Then those theorems are... well "UNPROVEN" theorems. PERIOD.
>
> Actually, I agree with Jacob here. Here is a mathematical definition
> of theorem, and I think it agrees with the general sense:
> http://mathworld.wolfram.com/Theorem.html

I side with R.H. on this, that is to receive the status of a *theorem*,
there should exist a proof.

If the mathematical statement is believed to be true, but no proof exist
yet, a better wording is *conjecture* or *hypothesis*.

However, a proof might not be correct, and I see no point in insisting
on formal proofs over computer assisted proofs.

--
Tor <bwzcab@wvtqvm.vw | tr i-za-h a-z>

Keith Thompson wrote:
> jacob navia <jacob@nospam.com> writes:
>> J. J. Farrell wrote:
>>> Why do you insist on making a fool of yourself with silly sarcasm
>>> like this? You've found evidence that Heathfield's statement was
>>> wrong, and you've presented it. Why follow it with this ridiculous
>>> nonsense? Crow about proving him wrong if you like, but parading
>>> this big chip on your shoulder just makes you look daft.
>> Well... you have a bit of truth here. The problem is that
>> I have the last discussions in my mind, and I can't
>> abstract from them so easily.
>
> Try harder.
>

>> Last time Mr Heathfield got carried away saying that strncmp
>> wasn't a string copy function... Incredible. When confronted
>> with evidence from the standard text, and from the semantics of
>> strncmp he argued that away. What surprised me was that nobody
>> (besides santosh) was ready to contradict him.

Well, I'm one of the many people who was unwilling to contradict Mr.
Heathfield, and there's a very simple reason for that: I didn't think he
was wrong. Jacob might want to consider the possibility that many of the
other silent ones also agreed with Mr. Heathfield, even if Jacob finds
that very difficult to imagine.

> Neither of the first two arguments to strncpy() needs to be a pointer
> to a string.

There's also the fact that it usually either does not copy the entire
string, not even bothering to properly null-terminate it, or writes a
lot of stuff in addition. Only rarely, in normal usage, does it write an
exact copy of the string, and nothing else.

There are other plausible ways of defining what is meant by a "string
copy function", but requiring that it always copy the entire string,
including the terminating null character, and write nothing more than
the string, seems like a reasonable requirement to me.

The other issue debated about strncpy() is whether it was actually any
use. Well, in my programs I routinely face the following situation:

The output file spec allows a fixed amount of space for an array of
characters. The input data that is to be written into that space will
usually be small enough to fit, but cannot be guaranteed to fit. When it
does not fit, it's not an error condition - I'm supposed to put as many
characters from the beginning of the input source into the output array
as possible. Losing the terminating characters is regrettable but
permissible. The character array can be null-terminated, but is not
required to be. However, to make binary comparison of output files
easier, every character after the terminating null should also be null.

The above description applies to many of the "strings" that my programs
have to write, and also to many of the strings that they must read. It
seems to me that strncpy() is tailor-made for such use.

James Kuyper <jameskuyper@verizon.net> writes:

> Keith Thompson wrote:
>> jacob navia <jacob@nospam.com> writes:
>>> J. J. Farrell wrote:
>>>> Why do you insist on making a fool of yourself with silly sarcasm
>>>> like this? You've found evidence that Heathfield's statement was
>>>> wrong, and you've presented it. Why follow it with this ridiculous
>>>> nonsense? Crow about proving him wrong if you like, but parading
>>>> this big chip on your shoulder just makes you look daft.
>>> Well... you have a bit of truth here. The problem is that
>>> I have the last discussions in my mind, and I can't
>>> abstract from them so easily.
>>
>> Try harder.
>>
>
>>> Last time Mr Heathfield got carried away saying that strncmp
>>> wasn't a string copy function... Incredible. When confronted
>>> with evidence from the standard text, and from the semantics of
>>> strncmp he argued that away. What surprised me was that nobody
>>> (besides santosh) was ready to contradict him.
>
> Well, I'm one of the many people who was unwilling to contradict
> Mr. Heathfield, and there's a very simple reason for that: I didn't
> think he was wrong. Jacob might want to consider the possibility that
> many of the other silent ones also agreed with Mr. Heathfield, even if
> Jacob finds that very difficult to imagine.

That doesn't necessarily ring true.

>
>> Neither of the first two arguments to strncpy() needs to be a pointer
>> to a string.
>
> There's also the fact that it usually either does not copy the entire
> string, not even bothering to properly null-terminate it, or writes a

"Not even bothering" what are you talking about? It is NOT supposed to.

> lot of stuff in addition. Only rarely, in normal usage, does it write
> an exact copy of the string, and nothing else.

Err, correct, for an exact copy we use strcpy. A different function.

>
> There are other plausible ways of defining what is meant by a "string
> copy function", but requiring that it always copy the entire string,
> including the terminating null character, and write nothing more than
> the string, seems like a reasonable requirement to me.

Yes it is reasonable. As is

,----
| The strncpy() function is similar, except that at most n bytes of src
| are copied. Warning: If there is no null byte among the first n
| bytes of src, the string placed in dest will not be null
| terminated.
`----

The "string placed in dest" is the clue.

You see what makes it so childishly simple is the "n" bit in the
name. it doesn't take a genius to figure out that n means
something. Possibly the number of characters to copy? Surely not!

>
> The other issue debated about strncpy() is whether it was actually any
> use. Well, in my programs I routinely face the following situation:
>
> The output file spec allows a fixed amount of space for an array of
> characters. The input data that is to be written into that space will
> usually be small enough to fit, but cannot be guaranteed to fit. When
> it does not fit, it's not an error condition - I'm supposed to put as
> many characters from the beginning of the input source into the output
> array as possible. Losing the terminating characters is regrettable
> but permissible. The character array can be null-terminated, but is
> not required to be. However, to make binary comparison of output files
> easier, every character after the terminating null should also be
> null.
>
> The above description applies to many of the "strings" that my
> programs have to write, and also to many of the strings that they must
> read. It seems to me that strncpy() is tailor-made for such use.

It is nonsense to decry strncpy because some programmers can't be arsed
to read the manual properly IMO.

ps, Why is Heathfield, "Mr Heathfield" and Mr Navia is "Jacob" to you?
Are you emulating Heathfield's writing style here? Alas!

In article <mg4605-ss4.ln1@news.individual.net>,
Richard <rgrdev@gmail.com> wrote in response to some punter:
....
>ps, Why is Heathfield, "Mr Heathfield" and Mr Navia is "Jacob" to you?
>Are you emulating Heathfield's writing style here? Alas!

Except that he got it backwards. The hyperventilating style assumed by
Dickie H is to refer to the people you don't like as "Mr." and the ones
you do by their full names (or, occasionally, by their first names only).
This is a fairly common hack (inter alia, in the biz world); it was by
no means invented by our own Dickie H.

The punter to which rgrdev responded couldn't even get that right, and
dropped down into schoolboy/playground-speak. On the playground, you
refer to the people in power as "Mr.", and, of course, refer to the
people you're beating up on by their first names.

Richard wrote:
....
> ps, Why is Heathfield, "Mr Heathfield" and Mr Navia is "Jacob" to you?
> Are you emulating Heathfield's writing style here? Alas!

No. I normally don't bother with "Mr." or "Mrs." for anybody, certainly
not for myself, and I routinely use first names when known, unless they
are ambiguous within the group that I'm speaking to (for example, the
multiple "Richards" who are regulars on this newsgroup). Most of the
people I deal with have no problem with that, or at least none that
they've bothered to express to me. However, I recently got reprimanded
by someone who considered it a serious insult that I didn't refer to him
as "Mr. X", whatever "X" was (I don't remember). As a reaction to that
incident, I sometimes inconsistently switch from my normal usage.

James Kuyper <jameskuyper@verizon.net> writes:

> Richard wrote:
> ...
>> ps, Why is Heathfield, "Mr Heathfield" and Mr Navia is "Jacob" to you?
>> Are you emulating Heathfield's writing style here? Alas!
>
> No. I normally don't bother with "Mr." or "Mrs." for anybody,
> certainly not for myself, and I routinely use first names when known,
> unless they are ambiguous within the group that I'm speaking to (for
> example, the multiple "Richards" who are regulars on this

I don't think it is necessary to litter a reply with names. It's all
self evident, generally, to whom one is referring thanks to a wonderful
invention called message threads and quoting.

> newsgroup). Most of the people I deal with have no problem with that,
> or at least none that they've bothered to express to me. However, I
> recently got reprimanded by someone who considered it a serious insult
> that I didn't refer to him as "Mr. X", whatever "X" was (I don't
> remember). As a reaction to that incident, I sometimes inconsistently
> switch from my normal usage.

Frankly I think calling anyone "Mr this" or "Mr that" is talking down
and appearing to rather take the high horse approach. As is evident from
the certain posts here.

Still, all to their own.

Richard wrote:
....
> I don't think it is necessary to litter a reply with names. It's all
> self evident, generally, to whom one is referring thanks to a wonderful
> invention called message threads and quoting.

The original draft of the message in question was filled with "he" and
"him" and "his". I only replaced them with actual names when I
realized that it was often unclear who I was referring to.

Keith Willis <me@privacy.net> writes:

> On Mon, 05 Nov 2007 22:53:11 +0100, jacob navia <jacob@nospam.com>
> wrote:
>
>>http://dictionary.reference.com/browse/theorem
>>
> <snip>
>>
>>Can you read?
>>"something to be proved from other propositions or formulas" (1)
>
> I'll see your dictionary and raise you one:
>
> http://www.askoxford.com/concise_oed/theorem?view=uk
>
> "a general proposition not self-evident but proved by a chain of
> reasoning"

....and I'll raise you to the full OED:

"a. In Mathematics and Physics; spec. in Geometry, a proposition
embodying merely something to be proved..."[1]

Presumably the argument here is whether the "loose" sense of something
asserted and not yet proved (or disproved) is in the dictionary. Of
course, the OED gives the usual, stricter, meaning above this one.

For what it is worth, I am with RH on this (despite the detail from
the dictionary) because I don't think the Church-Turing thesis can be
formulated as a theorem (or, better, a conjecture) because it is by
its nature vague about the formality.

[1] The "merely" here refers to the stronger notion of a "problem" in
geometry -- something to be done (like squaring the circle) rather
than "merely" proved or disproved.

--
Ben.

gazelle@xmission.xmission.com (Kenny McCormack) writes:

> In article <mg4605-ss4.ln1@news.individual.net>,
> Richard <rgrdev@gmail.com> wrote in response to some punter:
> ...
>>ps, Why is Heathfield, "Mr Heathfield" and Mr Navia is "Jacob" to you?
>>Are you emulating Heathfield's writing style here? Alas!
>
> Except that he got it backwards. The hyperventilating style assumed by
> Dickie H is to refer to the people you don't like as "Mr." and the ones
> you do by their full names (or, occasionally, by their first names only).
> This is a fairly common hack (inter alia, in the biz world); it was by
> no means invented by our own Dickie H.
>
> The punter to which rgrdev responded couldn't even get that right, and
> dropped down into schoolboy/playground-speak. On the playground, you
> refer to the people in power as "Mr.", and, of course, refer to the
> people you're beating up on by their first names.

Slight corrections : their sirnames.

As in "You 'ad enuff yet McCormack?!?!" (sound of boot going in).

"James Kuyper" <jameskuyper@verizon.net> a écrit dans le message de news:
ATYXi.18208$Cb.8518@trnddc08...
> Keith Thompson wrote:
>> jacob navia <jacob@nospam.com> writes:
>>> J. J. Farrell wrote:
>>>> Why do you insist on making a fool of yourself with silly sarcasm
>>>> like this? You've found evidence that Heathfield's statement was
>>>> wrong, and you've presented it. Why follow it with this ridiculous
>>>> nonsense? Crow about proving him wrong if you like, but parading
>>>> this big chip on your shoulder just makes you look daft.
>>> Well... you have a bit of truth here. The problem is that
>>> I have the last discussions in my mind, and I can't
>>> abstract from them so easily.
>>
>> Try harder.
>>
>
>>> Last time Mr Heathfield got carried away saying that strncmp
>>> wasn't a string copy function... Incredible. When confronted
>>> with evidence from the standard text, and from the semantics of
>>> strncmp he argued that away. What surprised me was that nobody
>>> (besides santosh) was ready to contradict him.
>
> Well, I'm one of the many people who was unwilling to contradict Mr.
> Heathfield, and there's a very simple reason for that: I didn't think he
> was wrong. Jacob might want to consider the possibility that many of the
> other silent ones also agreed with Mr. Heathfield, even if Jacob finds
> that very difficult to imagine.
>
>> Neither of the first two arguments to strncpy() needs to be a pointer
>> to a string.
>
> There's also the fact that it usually either does not copy the entire
> string, not even bothering to properly null-terminate it, or writes a lot
> of stuff in addition. Only rarely, in normal usage, does it write an exact
> copy of the string, and nothing else.

The fact that it does not produce a 'string' is not a necessary condition to
qualify as a 'string function', take strlen for instance.

> There are other plausible ways of defining what is meant by a "string copy
> function", but requiring that it always copy the entire string, including
> the terminating null character, and write nothing more than the string,
> seems like a reasonable requirement to me.

Nobody questions that. The reasons strncpy is labelled as a string function
are simple:
- it is defined in <string.h>
- it is documented in the standard in chapter 7.21 String handling
- it's behaviour is somewhat specific when it is passed a string shorter
than its numeric argument.

> The other issue debated about strncpy() is whether it was actually any
> use. Well, in my programs I routinely face the following situation:
>
> The output file spec allows a fixed amount of space for an array of
> characters. The input data that is to be written into that space will
> usually be small enough to fit, but cannot be guaranteed to fit. When it
> does not fit, it's not an error condition - I'm supposed to put as many
> characters from the beginning of the input source into the output array as
> possible. Losing the terminating characters is regrettable but
> permissible. The character array can be null-terminated, but is not
> required to be. However, to make binary comparison of output files easier,
> every character after the terminating null should also be null.
>
> The above description applies to many of the "strings" that my programs
> have to write, and also to many of the strings that they must read. It
> seems to me that strncpy() is tailor-made for such use.

You are making this up ;-)
If you are dealing with binary files, strncpy is not the final answer to
your problem, you have to perform I/O as well and the intermediary buffer is
wasteful. A 'tailor-made' solution to your problem is this:

int write_string_field(FILE *fp, size_t count, const char *str) {
while (count > 0 && *str) {
putc(*str++, fp);
count--;
}
while (count > 0) {
putc(0, fp);
count--;
}
return ferror(fp);
}

--
Chqrlie.

"Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de news:
Oe6dnZXqh8C3vLLanZ2dnUVZ8qClnZ2d@bt.com...
> Richard Bos said:
>
> <snip>
>
>> The fundamental theorem, which has not even
>> been proved (though there is a great deal of circumstantial evidence for
>> it, and none against)
>
> Oh my dear chap, you're beginning to make a bit of a habit of being wrong,
> aren't you? If it's a theorem, it *has* been proved. If it has not been
> proved, it is not a theorem. (Fermat's Last Theorem was for centuries a
> misnomer, because it hasn't been proved. Now it's a misnomer because the
> proof was supplied by Wiles, not Fermat.)

Fermat claimed to have proved his conjecture, and wrote his friends about
his 'marvelous' discovery. His proof was never found, and thus the
'theorem' remained unproved for more than three centuries. The greatest
mathematicians have spent immense efforts trying to prove it, and eventually
conjectured that Fermat himself did not have proof for it, or that his proof
was incorrect. But they did not reformulate the famous problem as 'the
Fermat conjecture'.

Finally came Andrew Wiles, who discovered a very indirect and complex way to
prove it and bridge different fields of mathematics. That is definitely
'Wiles proof', but it does not make Fermat's 'marvelous' discovery less his.

--
Chqrlie.

"Richard" <rgrdev@gmail.com> a écrit dans le message de news:
mg4605-ss4.ln1@news.individual.net...
>
> It is nonsense to decry strncpy because some programmers can't be arsed
> to read the manual properly IMO.

Just reflect on this bold statement next time you are seated in an aircraft.
Wouldn't you want software to be written with less easy to misuse library
functions, *even* if 'some programmers can't be arsed to read the manual
properly' ?

--
Chqrlie.

Charlie Gordon said:

<snip>

> The fact that it does not produce a 'string' is not a necessary condition
> to qualify as a 'string function', take strlen for instance.

The fact that it does not either require a string as input nor yield a
string as output might, however, give one pause for thought.

<snip>

> The reasons strncpy is labelled as a string
> function

....by some people...

> are simple:
> - it is defined in <string.h>

....like mem*, and unlike strtol, strtoul, strtod...

> - it is documented in the standard in chapter 7.21 String handling

....like mem*, and unlike strtol, strtoul, strtod...

> - it's behaviour is somewhat specific when it is passed a string shorter
> than its numeric argument.

....like printf("%*s\n", 20, "Hello");

None of these reasons seems to me to be particularly compelling.

<snip excellent example from James K of situation where strncpy is useful>

>> The above description applies to many of the "strings" that my programs
>> have to write, and also to many of the strings that they must read. It
>> seems to me that strncpy() is tailor-made for such use.
>
> You are making this up ;-)

Despite the smiley, that's a rather offensive suggestion, isn't it?

> If you are dealing with binary files, strncpy is not the final answer to
> your problem, you have to perform I/O as well and the intermediary buffer
> is wasteful.

Has it occurred to you that he might have other processing to do on that
buffer before writing it to file?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

Richard Heathfield wrote:
[snip]

1) The standard says:
7.21 String Handling
Later:
7.21.2: Copying functions
Later:
7.21.2.3: The strncpy function.

But this is no proof for Mr Heathfield. He will
insist forever his nonsense. strncpy is not
for string copying.

There is no blinder man as the one that doesn't want to see.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

Charlie Gordon said:

<snip>

> Fermat claimed to have proved his conjecture, and wrote his friends about
> his 'marvelous' discovery. His proof was never found,

....if it ever existed...

> and thus the
> 'theorem' remained unproved for more than three centuries.

Right. An unpublished proof, as far as the mathematics community is
concerned, might as well not exist. I have an interesting demonstration of
this fact, but this Usenet article is too large to contain it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

jacob navia <jacob@nospam.com> writes:

> Richard Heathfield wrote:
> [snip]
>
> 1) The standard says:
> 7.21 String Handling
> Later:
> 7.21.2: Copying functions
> Later:
> 7.21.2.3: The strncpy function.
>
> But this is no proof for Mr Heathfield. He will
> insist forever his nonsense. strncpy is not
> for string copying.
>
> There is no blinder man as the one that doesn't want to see.

In the valley of the blind, the one eyed man is king.

On Nov 5, 3:41 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> pete said:
>
>
>
>
>
> > Chris Dollin wrote:
>
> >> Richard Heathfield wrote:
>
> >> > Oh my dear chap,
> >> > you're beginning to make a bit of a habit of being wrong,
> >> > aren't you? If it's a theorem, it *has* been proved.
> >> > If it has not been proved, it is not a theorem.
>
> >> Richard is referring (if I am not mistaken)
> >> to the Church-Turing /thesis/.
>
> > I don't know about that, but my entire tenth grade math education
> > consisted of memorizing a few axioms
> > and proofs of ten fundamental theorems,
> > which I then used to proove other theorems
> > and so on and so forth, for the rest of the year.
>
> > In physics the following year,
> > I learned of the hierarchy of observation, conjecture,
> > hypothesis, theory, and law;
> > in which "theories"
> > are not generally considered to have been prooven.
>
> Yes, but there is a difference between a "theory" (which is a science
> concept) and a "theorem" (which is a formal systems concept).

True, but they are closely related:
http://www.etymonline.com/index.php?...earchmode=none

theorem
1551, from M.Fr. théorème, from L.L. theorema, from Gk. theorema
"spectacle, speculation," in Euclid "proposition to be proved," from
theorein "to consider" (see theory).

Charlie Gordon wrote:
> "James Kuyper" <jameskuyper@verizon.net> a écrit dans le message de news:
....
> > There's also the fact that it usually either does not copy the entire
> > string, not even bothering to properly null-terminate it, or writes a lot
> > of stuff in addition. Only rarely, in normal usage, does it write an exact
> > copy of the string, and nothing else.
>
> The fact that it does not produce a 'string' is not a necessary conditionto
> qualify as a 'string function', take strlen for instance.

True, but I was specifically responding to a message referring to
"string copy" functions, not just "string" functions. A "string copy"
function that doesn't always copy the entire string, and sometimes
creates an output that is a lot larger than the string that is to be
copied is arguably mislabeled.

> > The other issue debated about strncpy() is whether it was actually any
> > use. Well, in my programs I routinely face the following situation:
> >
> > The output file spec allows a fixed amount of space for an array of
> > characters. The input data that is to be written into that space will
> > usually be small enough to fit, but cannot be guaranteed to fit. When it
> > does not fit, it's not an error condition - I'm supposed to put as many
> > characters from the beginning of the input source into the output arrayas
> > possible. Losing the terminating characters is regrettable but
> > permissible. The character array can be null-terminated, but is not
> > required to be. However, to make binary comparison of output files easier,
> > every character after the terminating null should also be null.
> >
> > The above description applies to many of the "strings" that my programs
> > have to write, and also to many of the strings that they must read. It
> > seems to me that strncpy() is tailor-made for such use.
>
> You are making this up ;-)

No.

> If you are dealing with binary files, strncpy is not the final answer to
> your problem, you have to perform I/O as well and the intermediary bufferis
> wasteful. A 'tailor-made' solution to your problem is this:

The third-party library function that performs the actual writing
requires a buffer. What actually ends up in the output file is not
just the array itself, but also the name, dimensions, and XDR datatype
of the array.

Richard <rgrdev@gmail.com> writes:
> James Kuyper <jameskuyper@verizon.net> writes:
[...]
>> There are other plausible ways of defining what is meant by a "string
>> copy function", but requiring that it always copy the entire string,
>> including the terminating null character, and write nothing more than
>> the string, seems like a reasonable requirement to me.
>
> Yes it is reasonable. As is
>
> ,----
> | The strncpy() function is similar, except that at most n bytes of src
> | are copied. Warning: If there is no null byte among the first n
> | bytes of src, the string placed in dest will not be null
> | terminated.
> `----
>
> The "string placed in dest" is the clue.

It's a clue that the person who wrote that description of strncpy()
got it wrong. A "string" in C is null terminated by definition; if
it's not null terminated; it's not a string. C99 7.1.1p1: "A string
is a contiguous sequence of characters terminated by and including the
first null character."

The portion you quoted also doesn't say that null characters are
appended if the source array is a string shorter than n characters;
perhaps you just didn't include that part.

The existence of documentation that incorrectly describes the
strncpy() function doesn't prove that it's a "string function". Out
of curiosity, where did you get that description? If it's from a
current system, you might consider submitting a bug report.

> You see what makes it so childishly simple is the "n" bit in the
> name. it doesn't take a genius to figure out that n means
> something. Possibly the number of characters to copy? Surely not!
[...]

If I didn't know about the strncpy() function, and didn't have access
to the documentation, I'd probably assume that it's a safer version of
strcpy() that lets you specify the size of the target array. A call
like
strncpy(dest, source, n);
would (hypothetically) behave like strcpy(dest, source), except that
it wouldn't copy more than n characters in the dest array. If
strlen(source)+1 <= n, it would behave just like strcpy(dest, source).
Otherwise, it would copy the first n-1 characters of source into dest,
and set dest[n-1] to '\0'. It would not copy additional '\0'
characters into the dest array. In any case, as long as source points
to a valid string and dest points to an array of at least n
characters, dest would point to a valid string after the call.

In other words, this:
strncpy(dest, source, n);
would be equivalent to this:
dest[0] = '\0';
strncat(dest, source, n);

There are several other functions with an added 'n' in their names
that behave in this manner: strncat, snprinf, vsnprintf.

The behavior of strncpy() is *not obvious*. I completely agree that
programmers should not attempt to use it (or any other function)
without understanding how it works (though a beginning programmer
doesn't need to understand the details of format strings to write
``printf("hello, world\n");''). I don't mind having strncpy() in the
standard library, but I wish it had a different name, and I wish that
there were a strncpy() function that behaves as I've described above.
But it's far too late to make such a change.

Some questions:

What *exactly* do you mean by the phrase "string function"?

Does strncpy() meet your definition?

Do you use strncpy() in your own code?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"