Bug/Gross InEfficiency in HeathField's fgetline program

[Charlie Gordon]

user923005 said:

[...] the introduction of a discussion of
multiple currencies blurred the issue in my mind for a little while.
Taking a step back and thinking about it, I realised it represented a
completely separate issue.

I still stand by my statement that you can do double-entry
book-keeping
*exactly*.

I disagree. If there are any rational or exponential calculations,
then it is not possible.
Examples:
Depreciation calculations
Interest calculations
Investments (Future value, Present value, Annuities...)

Yes, but it's the same blurring. The "how much interest should be added?"
question cannot be answered exactly (except by chance, of course) - it
must be rounded. But double-entry book-keeping is about putting one
*monetary* amount into two ledgers, once on the debit side and once on
the
credit side. This can be done exactly.

I agree that the credit and the debit will agree. But the amount
stored is not exact. There have been schemes based on stealing these
fractional pennies that have netted huge sums over time.

This is akin to gleaning, which was not considered stealing in ancient
times.
These fractional pennies cannot be credited to cash deposit account holders,
is the bank stealing them ?

 

[Richard Bos]

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

 

[Charlie Gordon]

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.

 

[Charlie Gordon]

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.

 

[Charlie Gordon]

Charlie Gordon said:



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.



...by some people...


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


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


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

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.

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.

 

[Keith Willis]

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

 

[Richard Heathfield]

Charlie Gordon said:

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.

 

[William Hughes]

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

 

[James Kuyper]

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

 

[William Hughes]

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

 

[William Hughes]

"William Hughes" <[email protected]> a écrit dans le message de (e-mail address removed)...

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

- William Hughes

 

[James Kuyper]

"Richard Heathfield" <[email protected]> a écrit dans le message de news: ....

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.

 

[Charlie Gordon]

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.

 

[Charlie Gordon]

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.

 

[Charlie Gordon]

Charlie Gordon said:



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()!


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

 

[Richard]

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.

 

[Richard Heathfield]

Charlie Gordon said:

"Richard Heathfield" <[email protected]> a écrit dans le message de
news: (e-mail address removed)...

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

 

[Dik T. Winter]

> "Dik T. Winter" <[email protected]> a écrit dans le message de
> (e-mail address removed)... ....
>
> 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.

 

[Charlie Gordon]

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.

 

[Charlie Gordon]

Charlie Gordon said:

"Richard Heathfield" <[email protected]> a écrit dans le message de
news: (e-mail address removed)...

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