<jameskuyper@verizon.net> a écrit dans le message de news:
1194378323.424383.294770@k79g2000hse.googlegroups. com...
> 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 condition
>> to
>> 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.

I agree: strncpy is *definitely* mislabeled.
Furthermore, I advocate there is no justification for its inclusion in the
Standard.
It was a historical mistake, just like forgetting or deliberately excluding
the much more useful strdup function (as defined in Posix).

The usual argument that strdup is easy to write in terms of standard
functions does not hold: atoi and friends are easy to write with strtoxxx,
and for that matter, strncpy is quite easy to write too.

>>> 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 ;-)
>
> 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 buffer
>> is
>> 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.

OK, you have one of the very few examples where strncpy is the right tool
for the job, but it would not have been much of a problem if it had not been
part of the standard and you had to write a 'tailor-made' utility for this
need.

--
Chqrlie.

"Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de news:
I7Kdnf5v8bGaK63aRVnyiwA@bt.com...
> 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...

correct, as I mentioned in content that you snipped.

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

Mathematics was like a game of twits then... making Fermat's Last Theorem
one of the longest running jokes of all time.

--
Chqrlie.

William Hughes <wpihughes@hotmail.com> wrote:

> On Nov 6, 1:42 pm, jacob navia <ja...@nospam.com> wrote:
> > Richard Heathfield wrote:
> >
> > 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.
>
> A bit silly. The question is whether strncpy is a "string function".
>
> For: the name starts with str and it is described in 7.21 String
> Handling
>
> Against: the fact that it does not take or produce a string

s/does/need/. It _can_ be used to work exclusively with real C strings -
it just takes more work and attention than should be necessary.

IMO it _is_ a string function, but a severely broken one.

Richard

"Richard Bos" <rlb@hoekstra-uitgeverij.nl> a écrit dans le message de news:
4731651a.1706823211@news.xs4all.nl...
> William Hughes <wpihughes@hotmail.com> wrote:
>
>> On Nov 6, 1:42 pm, jacob navia <ja...@nospam.com> wrote:
>> > Richard Heathfield wrote:
>> >
>> > 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.
>>
>> A bit silly. The question is whether strncpy is a "string function".
>>
>> For: the name starts with str and it is described in 7.21 String
>> Handling
>>
>> Against: the fact that it does not take or produce a string
>
> s/does/need/. It _can_ be used to work exclusively with real C strings -
> it just takes more work and attention than should be necessary.
>
> IMO it _is_ a string function, but a severely broken one.

Hence my advice: just don't use it.

--
Chqrlie.

"William Hughes" <wpihughes@hotmail.com> a écrit dans le message de news:
1194396428.646191.297970@v3g2000hsg.googlegroups.c om...
>
> I would prefer an operational definition:
>
> C: a string function is a function that is more
> commonly used to handle strings, than for other purposes.
>
> Like many operational definitions this is a little
> fuzzy, but I would claim that using definition C, strncpy is not a
> string function.

I like this definition, as it describes fairly accurately the status of
strncpy in common use: this misnamed braindead easy-to-misuse thing is
indeed commonly used to handle strings, but it does not do that in the way a
lot of users expect. I propose a truce in this everlasting debate:
programmers that think of strncpy as a string function should not use it as
their misconception about its semantics will produce bogus code.

> When discussing definitions we are getting close to
> "De Gustibus ...". However, in matters of taste there is no
> obvious.

Not everything is a matter of taste, effectiveness matters: completely
unindented code is error prone, mis indented code is even worse, and easy to
misuse APIs are problematic as well.

--
Chqrlie.

"Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de news:
I7Kdnf1v8bHILq3aRVnyiwA@bt.com...
> 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.

Actually, I don't know why I am arguing with you on this issue: I can't
think of any compelling reason to even include this function in the
Standard. I don't care if it is a string or a utility function, I want it
deprecated.

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

Useful is a bit strong. strncpy happens to be exactly what James needs in
his tailor-made example. But the availability of strncpy did not save him
much: he could have easily written a replacement with a more appropriate
name.

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

No offense intended, really, in addition to the smiley, I should have made
it sound more like a question.

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

He does, and I'm not surprised.

--
Chqrlie.

On Tue, 06 Nov 2007 19:42:59 +0100, jacob navia <jacob@nospam.com>
wrote:

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

You know, I'm rather tired of reading insulting and unnecessary
comments from you, both here and elsewhere. Go spend a month in the
fill-filter.
<*plonk*>
--
PGP key ID 0xEB7180EC

Charlie Gordon said:

<snip>

> Actually, I don't know why I am arguing with you on this issue: I can't
> think of any compelling reason to even include this function in the
> Standard.

Neither can I - but now that it's in there, you'd have to come up with a
very convincing argument for taking it out. Look how many decades it took
to get rid of gets()!

> I don't care if it is a string or a utility function, I want
> it deprecated.

<shrug> I don't think that's going to happen. I don't actually care either
way, but *right now* it's there, it's part of C, and so people will
occasionally ask questions about it. Clearly it has a use. Equally
clearly, it's a rather obscure use and in any case it's pretty easy to
roll your own if you actually need that functionality. Equally equally
clearly, it is misused, and equally equally equally clearly, it is
sometimes misused so badly as to constitute abuse.

To say "never use it" is overly strong, as it is in cases such as, say,
strtok - "never" should be reserved for gets(), scanf("%s", and the like.
But it is used far more than it should be used. The intent is noble but
the effect is dangerous.

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

On Nov 7, 2:13 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> William Hughes <wpihug...@hotmail.com> wrote:
> > On Nov 6, 1:42 pm, jacob navia <ja...@nospam.com> wrote:
> > > Richard Heathfield wrote:
>
> > > 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.
>
> > A bit silly. The question is whether strncpy is a "string function".
>
> > For: the name starts with str and it is described in 7.21 String
> > Handling
>
> > Against: the fact that it does not take or produce a string
>
> s/does/need/. It _can_ be used to work exclusively with real C strings -
> it just takes more work and attention than should be necessary.
>
> IMO it _is_ a string function, but a severely broken one.
>
> Richard

William Hughes wrote:
....
> Clearly we cannot decide the question without a definition for "string
> function".
>
> We could try
>
> A: a string function starts str and is defined in 7.21
>
> or
> B: a string function either requires or always produces a string

There's a key question that should be asked whenever you're trying to
decide what the best definition should be for a given phrase: what do
you want to say about things matching that definition? I'm not referring
to statements that describe the definition; I'm talking about statements
that state provide useful advice which is true because that definition
is true. Once you know what you want to say about string functions, that
will you determine how they should be defined.

For instance, if you want to say that "The output of a string function
is always a null terminated string that is suitable for use as input to
other string functions", then your definition A above is clearly
inappropriate, since it includes strncpy(); B is the better choice.

If you want to say that "To find the definition of a string function,
you can look in section 7.21 of the C standard for a function whose name
starts with str.", then definition B is clearly wrong, because it
defines many things that aren't even part of the C standard library as
being string functions. You're definition A is clearly a better match,
but it has one key problem: that statement becomes circular. How do you
know that what you want to look for is a string function? Since the
definition is in terms of where the function is defined, rather than in
terms of what the function does, how is a programmer supposed to know
that he's looking for a string function?

I can't come up with a useful statement about string functions for which
your definition A is the best one. The first example I gave above is a
useful statement about string functions that requires something similar
to your definition B. That's why I favor definition B.

On Nov 7, 2:13 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> William Hughes <wpihug...@hotmail.com> wrote:
> > On Nov 6, 1:42 pm, jacob navia <ja...@nospam.com> wrote:
> > > Richard Heathfield wrote:
>
> > > 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.
>
> > A bit silly. The question is whether strncpy is a "string function".
>
> > For: the name starts with str and it is described in 7.21 String
> > Handling
>
> > Against: the fact that it does not take or produce a string
>
> s/does/need/.
>

Of course I pointed out this fact, and noted that it makes a
definiton based on what arguments are needed, rather
that what arguments are normally used, less than
compelling.


> It _can_ be used to work exclusively with real C strings -
> it just takes more work and attention than should be necessary.
>
> IMO it _is_ a string function, but a severely broken one.
>

If you want to claim it is a "string function" it behooves you
to define "string function". Try reading my post.
It might give you some ideas for a good definition.


- William Hughes

On Nov 7, 5:48 am, "Charlie Gordon" <n...@chqrlie.org> wrote:
> "William Hughes" <wpihug...@hotmail.com> a écrit dans le message de news:
> 1194396428.646191.297...@v3g2000hsg.googlegroups.c om...

>
> > When discussing definitions we are getting close to
> > "De Gustibus ...". However, in matters of taste there is no
> > obvious.
>
> Not everything is a matter of taste, effectiveness matters: completely
> unindented code is error prone, mis indented code is even worse, and easyto
> misuse APIs are problematic as well.
>

And as none of your examples touches on definitions, I fail to see
your
point. Not everything is a matter of taste, not even every argument
about definitions. However, many arguments about definitions are
about
a matter of taste. In these arguments is is silly to say
that a given definition is "obvious".

- William Hughes

Charlie Gordon wrote:
> "Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de news:
....
>> <snip excellent example from James K of situation where strncpy is useful>
>
> Useful is a bit strong. strncpy happens to be exactly what James needs in
> his tailor-made example.

I did not tailor my example to fit strncpy(). It is a real-world
situation I actually face frequently on my current project. I will
readily grant that it is an unusual one. If an input that must be copied
to an output has a variable length, I would normally expect either that
the output format also allows the length to be variable, or that the
fixed length of that output is sufficiently large to accommodate all
legal inputs, and that any input which exceeds that limit is treated as
an error.

I didn't design the layouts of the output files where this issue comes
up, and I cannot change them in any way that makes them incompatible
with code designed to read the old format. However, when I have had the
freedom to do so, I've used a more appropriate approach.

"William Hughes" <wpihughes@hotmail.com> a écrit dans le message de news:
1194439578.941710.160010@d55g2000hsg.googlegroups. com...
> On Nov 7, 5:48 am, "Charlie Gordon" <n...@chqrlie.org> wrote:
>> "William Hughes" <wpihug...@hotmail.com> a écrit dans le message de news:
>> 1194396428.646191.297...@v3g2000hsg.googlegroups.c om...
>>
>>> When discussing definitions we are getting close to
>>> "De Gustibus ...". However, in matters of taste there is no
>>> obvious.
>>
>> Not everything is a matter of taste, effectiveness matters: completely
>> unindented code is error prone, mis indented code is even worse, and easy
>> to
>> misuse APIs are problematic as well.
>
> And as none of your examples touches on definitions, I fail to see
> your point. Not everything is a matter of taste, not even every
> argument about definitions. However, many arguments about definitions
> are about a matter of taste. In these arguments is is silly to say
> that a given definition is "obvious".

My point is that it does not matter so much whether strncpy is a "string
function" or not, or what formal definition for "string functions" the
various regulars can or cannot agree upon after yet another session of
collaborative mental masturbation. More than just a matter of taste, the
problems with strncpy semantics and general misuse make it generally
detestable.

--
Chqrlie.

"James Kuyper" <jameskuyper@verizon.net> a écrit dans le message de news:
GziYi.20137$Rg1.9865@trnddc05...
> Charlie Gordon wrote:
>> "Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de
>> news:
> ...
>>> <snip excellent example from James K of situation where strncpy is
>>> useful>
>>
>> Useful is a bit strong. strncpy happens to be exactly what James needs
>> in his tailor-made example.
>
> I did not tailor my example to fit strncpy(). It is a real-world situation
> I actually face frequently on my current project. I will readily grant
> that it is an unusual one. If an input that must be copied to an output
> has a variable length, I would normally expect either that the output
> format also allows the length to be variable, or that the fixed length of
> that output is sufficiently large to accommodate all legal inputs, and
> that any input which exceeds that limit is treated as an error.
>
> I didn't design the layouts of the output files where this issue comes up,
> and I cannot change them in any way that makes them incompatible with code
> designed to read the old format. However, when I have had the freedom to
> do so, I've used a more appropriate approach.

Sorry for the unintended wit, I meant your example is a perfect fit, like a
taylor-made suit, as you said it yourself.

--
Chqrlie.

"Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de news:
ddydnesN7r6zP6zanZ2dneKdnZydnZ2d@bt.com...
> Charlie Gordon said:
>
> <snip>
>
>> Actually, I don't know why I am arguing with you on this issue: I can't
>> think of any compelling reason to even include this function in the
>> Standard.
>
> Neither can I - but now that it's in there, you'd have to come up with a
> very convincing argument for taking it out. Look how many decades it took
> to get rid of gets()!
>
>> I don't care if it is a string or a utility function, I want
>> it deprecated.
>
> <shrug> I don't think that's going to happen. I don't actually care either
> way, but *right now* it's there, it's part of C, and so people will
> occasionally ask questions about it. Clearly it has a use. Equally
> clearly, it's a rather obscure use and in any case it's pretty easy to
> roll your own if you actually need that functionality. Equally equally
> clearly, it is misused, and equally equally equally clearly, it is
> sometimes misused so badly as to constitute abuse.
>
> To say "never use it" is overly strong, as it is in cases such as, say,
> strtok - "never" should be reserved for gets(), scanf("%s", and the like.
> But it is used far more than it should be used. The intent is noble but
> the effect is dangerous.

So we are 99% in agreement on this issue.

--
Chqrlie.

"Charlie Gordon" <news@chqrlie.org> writes:

> "William Hughes" <wpihughes@hotmail.com> a écrit dans le message de news:
> 1194439578.941710.160010@d55g2000hsg.googlegroups. com...
>> On Nov 7, 5:48 am, "Charlie Gordon" <n...@chqrlie.org> wrote:
>>> "William Hughes" <wpihug...@hotmail.com> a écrit dans le message de news:
>>> 1194396428.646191.297...@v3g2000hsg.googlegroups.c om...
>>>
>>>> When discussing definitions we are getting close to
>>>> "De Gustibus ...". However, in matters of taste there is no
>>>> obvious.
>>>
>>> Not everything is a matter of taste, effectiveness matters: completely
>>> unindented code is error prone, mis indented code is even worse, and easy
>>> to
>>> misuse APIs are problematic as well.
>>
>> And as none of your examples touches on definitions, I fail to see
>> your point. Not everything is a matter of taste, not even every
>> argument about definitions. However, many arguments about definitions
>> are about a matter of taste. In these arguments is is silly to say
>> that a given definition is "obvious".
>
> My point is that it does not matter so much whether strncpy is a "string
> function" or not, or what formal definition for "string functions" the
> various regulars can or cannot agree upon after yet another session of
> collaborative mental masturbation. More than just a matter of taste, the
> problems with strncpy semantics and general misuse make it generally
> detestable.

Only in your world where you seem to have a problem understanding the
clearly documented API.

Charlie Gordon said:

> "Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de
> news: ddydnesN7r6zP6zanZ2dneKdnZydnZ2d@bt.com...

<snip>

>> To say "never use [strncpy]" is overly strong, as it is in cases
>> such as, say, strtok - "never" should be reserved for gets(),
>> scanf("%s", and the like. But it is used far more than it should
>> be used. The intent is noble but the effect is dangerous.
>
> So we are 99% in agreement on this issue.

Absolutely not!

It's more like 97.62%.

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

In article <4731bfcc$0$29916$426a74cc@news.free.fr> "Charlie Gordon" <news@chqrlie.org> writes:
> "Dik T. Winter" <Dik.Winter@cwi.nl> a écrit dans le message de news:
> Jr4zz3.FzM@cwi.nl...
....
> > > > Actually, I don't know why I am arguing with you on this issue: I
> > > > can't
> > > > think of any compelling reason to even include this function in the
> > > > Standard.
> > >
> > > Neither can I
> >
> > I can. Because it was in K&R C. And it was in K&R C to manipulate
> > file names in Unix V6 (maximal 14 characters, not necessarily null
> > terminated, but if shorter null filled).
>
> You are refering to the directory structure used in Unix V6, and some other
> obscure accounting files. That hardly qualifies as compelling for inclusion
> in c89. Such use was completely specific to the underlying operating
> system, just like the system calls. strdup was also present in K&R C, as an
> example from the book, but was not included in the Standard.

But strdup was *not* in the C library for K&R C, but strncpy *was*, and
it was there as a library function. Also already in early versions a
clear distinction was made between system calls and library functions,
so the comparison with system calls is invalid. When C became standardised
it was (I think) decided not to remove anything from the set of library
functions present in K&R C.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/

"Richard" <rgrdev@gmail.com> a écrit dans le message de news:
7ks805-0k6.ln1@news.individual.net...
> "Charlie Gordon" <news@chqrlie.org> writes:
>
>> "William Hughes" <wpihughes@hotmail.com> a écrit dans le message de news:
>> 1194439578.941710.160010@d55g2000hsg.googlegroups. com...
>>> On Nov 7, 5:48 am, "Charlie Gordon" <n...@chqrlie.org> wrote:
>>>> "William Hughes" <wpihug...@hotmail.com> a écrit dans le message de
>>>> news:
>>>> 1194396428.646191.297...@v3g2000hsg.googlegroups.c om...
>>>>
>>>>> When discussing definitions we are getting close to
>>>>> "De Gustibus ...". However, in matters of taste there is no
>>>>> obvious.
>>>>
>>>> Not everything is a matter of taste, effectiveness matters: completely
>>>> unindented code is error prone, mis indented code is even worse, and
>>>> easy
>>>> to
>>>> misuse APIs are problematic as well.
>>>
>>> And as none of your examples touches on definitions, I fail to see
>>> your point. Not everything is a matter of taste, not even every
>>> argument about definitions. However, many arguments about definitions
>>> are about a matter of taste. In these arguments is is silly to say
>>> that a given definition is "obvious".
>>
>> My point is that it does not matter so much whether strncpy is a "string
>> function" or not, or what formal definition for "string functions" the
>> various regulars can or cannot agree upon after yet another session of
>> collaborative mental masturbation. More than just a matter of taste, the
>> problems with strncpy semantics and general misuse make it generally
>> detestable.
>
> Only in your world where you seem to have a problem understanding the
> clearly documented API.

Why are you playing stupid? I know damn well what strncpy does an what is
does not. I am refering to the vast majority of programmers who think they
do but don't and misuse it conspicuously. I am certainly not hinting that
you be part of them, but you are deliberately ignoring the issue.

--
Chqrlie.

"Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de news:
TsudnXuiMbkZS6zaRVnyhwA@bt.com...
> Charlie Gordon said:
>
>> "Richard Heathfield" <rjh@see.sig.invalid> a écrit dans le message de
>> news: ddydnesN7r6zP6zanZ2dneKdnZydnZ2d@bt.com...
>
> <snip>
>
>>> To say "never use [strncpy]" is overly strong, as it is in cases
>>> such as, say, strtok - "never" should be reserved for gets(),
>>> scanf("%s", and the like. But it is used far more than it should
>>> be used. The intent is noble but the effect is dangerous.
>>
>> So we are 99% in agreement on this issue.
>
> Absolutely not!
>
> It's more like 97.62%.

1 - 1/42.

Sounds fair ;-)

--
Chqrlie.

"Charlie Gordon" <news@chqrlie.org> writes:
> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> a écrit dans le message de news:
> 4731651a.1706823211@news.xs4all.nl...
>> William Hughes <wpihughes@hotmail.com> wrote:
[...]
>>> A bit silly. The question is whether strncpy is a "string function".
>>>
>>> For: the name starts with str and it is described in 7.21 String
>>> Handling
>>>
>>> Against: the fact that it does not take or produce a string
>>
>> s/does/need/. It _can_ be used to work exclusively with real C strings -
>> it just takes more work and attention than should be necessary.
>>
>> IMO it _is_ a string function, but a severely broken one.
>
> Hence my advice: just don't use it.

I disagree.

A string function deals with a certain data structure, called a
"string" by the C standard, consisting of "a contiguous sequence of
characters terminated by and including the first null character" (C99
7.1.1p1).

strncpy() deals with a different data structure, one that has no name
that I'm aware of, consisting of an array of N characters of which the
first M are significant, and the remaining N-M characters are all set
to '\0', where M may be equal to N. Such a data structure happens to
contain a "string" *unless* M==N.

This latter data structure is not very commonly used, but as we've
seen it it used sometimes. If you happen to need it, strncpy() is
probably just the thing (though it would have been easy enough to roll
your own function for the purpose).

The facts that this relatively obscure data structure is supported in
the standard, that there's only one standard function that supports
it, and that that function has a name that misleadingly implies that
it's a string function, are all historical accidents. I don't recall
anyone claiming that the standard C library is a model of coherent
design.

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

Wow, just checking in on this thread again, and it seems to have taken
on a life of its own. It seems like a lifetime ago that it started with
some constructive criticism I made of some code by Richard HeathField's,
which he took with singularly bad grace.

On 6 Nov 2007 at 18:47, Richard Heathfield wrote:
> 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.

There are really two meanings of "theorem" being discussed.
Mathematicians use "theorem" all the time as a slightly loose word
denoting a statement of which an explicit proof is known (i.e. has been
written down completely, or experts believe they could write down
completely if forced to).

However, in meta-mathematics (a.k.a. logic), "theorem" has a precise
definition: in a logical system (i.e. a formal grammar plus a set of
axioms plus laws of deduction), a theorem is a sentence that can be
obtained by applying the axioms and laws of deduction a finite number of
times. So a sentence phi is a theorem if a proof exists (abstractly);
it's no more or less a theorem if no one's actually written down the
proof.

We certainly want our logical systems to be sound (i.e. any theorems we
prove should be true); ideally, we'd also like them to be complete (i.e.
we should be able to prove everything that's true). Simple logical
systems like propositional calculus and first-order logic are both sound
and complete; famously, second-order logic (needed to formulate modern
mathematics) was shown by Goedel not to be complete.