The function below is from Richard HeathField's fgetline program. For
some reason, it makes three passes through the string (a strlen(), a
strcpy() then another pass to change dots) when two would clearly be
sufficient. This could lead to unnecessarily bad performance on very
long strings. It is also written in a hard-to-read and clunky style.
char *dot_to_underscore(const char *s)
{
char *t = malloc(strlen(s) + 1);
if(t != NULL)
{
char *u;
strcpy(t, s);
u = t;
while(*u)
{
if(*u == '.')
{
*u = '_';
}
++u;
}
}
return
t;
}
Proposed solution:
char *dot_to_underscore(const char *s)
{
char *t, *u;
if(t=u=malloc(strlen(s)+1))
while(*u++=(*s=='.' ? s++, '_' : *s++));
return t;
}
Oct 7 '07
334  11240 
jacob navia <ja***@nospam.comwrites:
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.
And he's right; strncpy is not for string copying. In text that you
snipped, he presented multiple examples of string functions that are
not described in the "String handling" section of the standard (such
as strtol), as well as multiple examples of functions that are
described in that section that clearly are not string functions (such
as memcpy). So the fact that strncpy is described in the "String
handling" section proves nothing.
There is no blinder man as the one that doesn't want to see.
Indeed.
jacob, you are aware, aren't you, that the source (s2) argument of
strncpy(), unlike the corresponding argument of strcpy(), is not
required to point to a string? And that after a call to strncpy(),
the destination (s1) argument does not necessarily point to a string?
And that it typically appends multiple '\0' characters to the
destination, something that has nothing to do with string handling?
But the real question is this:
*What difference does it make?*
As long as you understand how strncpy() works (or, if you don't
understand it, as long as you avoid using it), it *doesn't matter*
whether you call it a "string function" or not. (That's a generic
"you"; I'm not accusing anyone of not understanding how strncpy()
works.) I'm taking the time to refute your arguments because you're
mistaken, not because the question itself is of any great importance.
I suspect that you (and a few others) are far more interested in
demonstrating that Richard Heathfield is wrong than in discussing C.
The fact that you've chosen to fight this particular battle over a
point on which he happens to be right is probably less significant
than your insistence on fighting it in the first place.
But if you must argue this point, try presenting some valid arguments.
The standard uses the phrase "string function" a few times, but it
doesn't define it. Present a definition of the phrase "string
function", so we can have some basis for determining whether strncpy()
is or isn't one. I suspect that for any definition I could come up
with, either it would be too contrived to be useful, or it would be so
broad that it would include fopen() (which IMHO should not be
considered a string function), or it would be narrow enough to exclude
both strncpy() and memcpy(). Show us your definition.
--
Keith Thompson (The_Other_Keith) ks***@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"
Flash Gordon said:
Richard Heathfield wrote, On 06/11/07 13:34:
>Flash Gordon said:
<snip>
>>I don't think that Richard believes he is always correct.
Interesting philosophical point there, Flash! :-)
As a matter of fact, I *do* think I'm correct, for the obvious reason
that, if I thought I were /in/correct, naturally I would modify my
position. (Doesn't everyone think that way?)
<snip>
You have misinterpreted my statement. I didn't say that you don't always
believe you are correct, I said that you don't believe you are always
correct. I.e. I stated that I believe you know that you are not perfect
and are sometimes incorrect, not that you state things that you believe
you are incorrect at the time you state them.
I sit corrected. And now that I understand what you meant, I agree.
I must take issue with santosh's response, though - your response was not
hair-splitting. It clarified an important distinction between two very
different ideas.
--
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 6, 1:42 pm, jacob navia <ja...@nospam.comwrote:
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.
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
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
I do not find either compelling. As to A I note that there are many
functions defined in 7.21 that are not string functions (e.g.
the mem* family). It seems as reasonable to say that strncpy is
misnamed as it is to say that strncpy is a string function.
Also there are function we would like to call string
functions that are not defined in 7.21, so this is at best a
sufficient
condition. As to B, I would want to characterize the function
by what is normally given and/or produced, not by the edge conditions.
Still, if forced at gunpoint to choose, I would probably pick B.
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.
When discussing definitions we are getting close to
"De Gustibus ...". However, in matters of taste there is no
obvious.
- William Hughes
Flash Gordon wrote:
Tor Rustad wrote, On 06/11/07 11:38:
[...]
This means that the only way to convert money from one currency
to another is to move it from one account to another, and
We call this a transaction, which typically is done with double-entry
bookkeeping.
at that point the rounding occurs as part of the conversion using
defined rules and a specified conversion rate,
"I'm struggling to imagine any real-world double-entry-relevant
calculation that /cannot/ be done exactly."
-RH
and those rules specify *exactly* what will be credited to one
account and debited from the other.
The whole point, is that this calculation uses rounding. Do UK accounts
have two decimal places?
>The obvious requirement our UK bank has, will be to match each account
at some cut-off times each day. This calculation should be done
*exactly*. If the currency conversion has already been done at this
point, there is no simple way to match the books *exactly*.
Incorrect, it is easy as long as you follow the requirements above.
Nothing you said, invalidated my statement here...
If anyone is interested enough I could ask one of my brothers who was
doing application support & maintenance for one of the large
organisations in the City of London that works with lots of currencies.
I have been trying to leave this thread for some time... :)
Anyway, some details from an insider is very interesting. In particular,
a related problem, how UK banks can implement SEPA w.r.t. double-entry
bookkeeping and risk management.
In this case, the transactions will be in euro, while the EU payment
scheme rulebook say nothing about possible currency conversion, or the
related risks for the banks.
I don't think that Richard believes he is always correct.
Neither did I. ;-)
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
<ja*********@verizon.neta écrit dans le message de news: 11**********************@k79g2000hse.googlegroups. com...
Charlie Gordon wrote:
>"James Kuyper" <ja*********@verizon.neta é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" <rj*@see.sig.invalida écrit dans le message de news: I7*********************@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.
"user923005" <dc*****@connx.coma écrit dans le message de news: 11**********************@o38g2000hse.googlegroups. com...
On Nov 5, 3:40 pm, Richard Heathfield <r...@see.sig.invalidwrote:
>user923005 said:
On Nov 3, 2:54 pm, Richard Heathfield <r...@see.sig.invalidwrote:
[...] 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 ?
--
Chqrlie.
jacob navia <ja***@nospam.comwrites:
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.
William Hughes <wp*******@hotmail.comwrote:
On Nov 6, 1:42 pm, jacob navia <ja...@nospam.comwrote:
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" <rl*@hoekstra-uitgeverij.nla écrit dans le message de news: 47*****************@news.xs4all.nl...
William Hughes <wp*******@hotmail.comwrote:
>On Nov 6, 1:42 pm, jacob navia <ja...@nospam.comwrote:
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" <wp*******@hotmail.coma écrit dans le message de news: 11**********************@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.
On Tue, 06 Nov 2007 19:42:59 +0100, jacob navia <ja***@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
On Nov 7, 2:13 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
William Hughes <wpihug...@hotmail.comwrote:
On Nov 6, 1:42 pm, jacob navia <ja...@nospam.comwrote:
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 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.
On Nov 7, 2:13 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
William Hughes <wpihug...@hotmail.comwrote:
On Nov 6, 1:42 pm, jacob navia <ja...@nospam.comwrote:
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.orgwrote:
"William Hughes" <wpihug...@hotmail.coma é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" <rj*@see.sig.invalida é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" <wp*******@hotmail.coma écrit dans le message de news: 11**********************@d55g2000hsg.googlegroups. com...
On Nov 7, 5:48 am, "Charlie Gordon" <n...@chqrlie.orgwrote:
>"William Hughes" <wpihug...@hotmail.coma écrit dans le message de news:
1194396428.646191.297...@v3g2000hsg.googlegroups. com...
>>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" <ja*********@verizon.neta écrit dans le message de news:
GziYi.20137$Rg1.9865@trnddc05...
Charlie Gordon wrote:
>"Richard Heathfield" <rj*@see.sig.invalida é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.
Charlie Gordon said:
"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: dd******************************@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
"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de news: Ts*********************@bt.com...
Charlie Gordon said:
>"Richard Heathfield" <rj*@see.sig.invalida écrit dans le message de
news: dd******************************@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" <ne**@chqrlie.orgwrites:
"Richard Bos" <rl*@hoekstra-uitgeverij.nla écrit dans le message de news:
47*****************@news.xs4all.nl...
>William Hughes <wp*******@hotmail.comwrote:
[...]
>>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) ks***@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"
"Tor Rustad" <to********@hotmail.comwrote in message
news:St*********************@telenor.com...
Flash Gordon wrote:
>Tor Rustad wrote, On 06/11/07 11:38:
>This means that the only way to convert money from one currency to
another is to move it from one account to another, and
We call this a transaction, which typically is done with double-entry
bookkeeping.
The only way to convert dollars into pounds is for the bank / the Americans
here to offer to swap their dollars with someone who has pounds. Like me,
except that as a private individual I've no real use for dollars.
You cannot pulp dollars and do a print run of the equivalent amount in
pounds.
It follows that any valuation of, say, a British company's dollar holdings
in pounds is a notional value. Based on market prices, they are saying what
they expect to be able to trade those dollars for. It doesn't differ in that
respect form their valuation of head office, or unsold inventory. Again,
there are rules, but these are best guess amounts that may not actually be
realised.
This has been explained to you in a previous post. Whilst a programmer
cannot be expected to have much understanding of the financial world, it is
not a very edifying sight to see you criticise Richard Heathfield so
vociferously, after you've been told once what the situation is.
--
Free games and programming goodies. http://www.personal.leeds.ac.uk/~bgy1mm
In data 06 Nov 2007 09:43:14 +0100, Jean-Marc Bourguet scrisse:
>user923005 <dc*****@connx.comwrites:
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...)
My impression was that there are reglementary texts who precise exactly how
those should be computed, included the rounding rules.
BTW, I doubt very much that they have any relationship with the rounding
rules of any implementation of floating point, even decimal FP. And we
know the problems caused by double rounding.
i don't know them...
can you please to give one simple example of it?
>Yours,
In article <vf********************************@4ax.comRoS <Ro*@not.existwrites:
In data 06 Nov 2007 09:43:14 +0100, Jean-Marc Bourguet scrisse:
....
BTW, I doubt very much that they have any relationship with the rounding
rules of any implementation of floating point, even decimal FP. And we
know the problems caused by double rounding.
i don't know them...
can you please to give one simple example of it?
If we use bankers rule as I understand it (if the first digit rounded
away is 0 to 4, we round down, otherwise we round up), starting with
0.3476 first to two decimals after the point and then to one decimal
we get first 0.35 and from that we get 0.4. Doing it directly we get 0.3.
And i understand that financial calculation and rounding rules are very
precise in the US.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Antoninus Twink said:
Wow, just checking in on this thread again, and it seems to have taken
on a life of its own.
Yes, it moved on to discuss real issues.
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.
Had the criticism been valid, it would have been welcome. A couple of other
recent threads have demonstrated this adequately. But your criticism was
broken and misguided, as the earlier part of this thread shows. Next time,
think and test before posting.
--
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
Tor Rustad wrote, On 07/11/07 01:00:
Flash Gordon wrote:
>Tor Rustad wrote, On 06/11/07 11:38:
[...]
>This means that the only way to convert money from one currency
to another is to move it from one account to another, and
We call this a transaction, which typically is done with double-entry
bookkeeping.
Indeed. We talk about transactions as well :-)
>at that point the rounding occurs as part of the conversion using
defined rules and a specified conversion rate,
"I'm struggling to imagine any real-world double-entry-relevant
calculation that /cannot/ be done exactly."
-RH
If you consider the rounding to to be part of the conversion equation
rather than something that is done afterwards then the calculation *is*
done exactly.
>and those rules specify *exactly* what will be credited to one account
and debited from the other.
The whole point, is that this calculation uses rounding.
It is part of the calculation, so the calculation overall is done exactly.
Do UK accounts
have two decimal places?
Yes.
>>The obvious requirement our UK bank has, will be to match each
account at some cut-off times each day. This calculation should be
done *exactly*. If the currency conversion has already been done at
this point, there is no simple way to match the books *exactly*.
Incorrect, it is easy as long as you follow the requirements above.
Nothing you said, invalidated my statement here...
I think we have a scoping problem. I consider the equation (restated) to be
100 =50
101 =50
102 =51
You consider it to be
101 =50.5
With a rounding done after.
>If anyone is interested enough I could ask one of my brothers who was
doing application support & maintenance for one of the large
organisations in the City of London that works with lots of currencies.
I have been trying to leave this thread for some time... :)
Well, on the application my brother was involved in they did use
floating point variables because no other variable type could cope with
the range. They just accepted that there would be errors and ensured
that they were consistent. Personally I think that was the wrong
decision, but...
Anyway, some details from an insider is very interesting. In particular,
a related problem, how UK banks can implement SEPA w.r.t. double-entry
bookkeeping and risk management.
That I don't know.
In this case, the transactions will be in euro, while the EU payment
scheme rulebook say nothing about possible currency conversion, or the
related risks for the banks.
They probably use whatever method they used before the euro :-)
>I don't think that Richard believes he is always correct.
Neither did I. ;-)
OK, we are all agree Richard makes mistakes. Whether we are talking
about the same Richard is, of course, another matter ;-)
--
Flash Gordon
Flash Gordon said:
Tor Rustad wrote, On 07/11/07 01:00:
<snip>
>>I don't think that Richard believes he is always correct.
Neither did I. ;-)
OK, we are all agree Richard makes mistakes.
Strictly speaking, we all agree that I don't believe he doesn't make
mistakes. That does not mean we all agree that I *do* make mistakes. Maybe
we do, and maybe we don't, but we haven't said so yet.
--
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, On 12/11/07 21:29:
Flash Gordon said:
>Tor Rustad wrote, On 07/11/07 01:00:
<snip>
>>>I don't think that Richard believes he is always correct.
Neither did I. ;-)
OK, we are all agree Richard makes mistakes.
Strictly speaking, we all agree that I don't believe he doesn't make
mistakes.
OK, can we all agree that I make mistakes?
That does not mean we all agree that I *do* make mistakes. Maybe
we do, and maybe we don't, but we haven't said so yet.
Well, I believe that Richard makes mistakes, but I'm not going to state
which Richard I am referring to yet.
--
Flash Gordon
Keith Thompson <ks...@mib.orgwrote:
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,
But still caters for strings.
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.
In the old days, this is what I called a record field, though
in some cases a space was used for padding rather than 0.
Fixed width fields, and checksums too apparently, are a thing
of the past.
<snip>
The facts that this relatively obscure data structure is
supported in the standard, that there's only one standard
function that supports it,
Huh? fread, fwrite, scanf, printf, memcpy, memcmp... to name
a few. And that's obviously excluding other constructs like
zero initialisation.
and that that function has a name that misleadingly implies
that it's a string function, are all historical accidents.
Merely historical in my opinion. I don't believe they were
an accident at the time. In those days, people were using
fixed width fields, and they were squeezing as much out of
limited memory as possible.
The function _can_ be used to copy prefixes of strings to
a string. And it _will_ terminate the destination with a
sufficiently large enough buffer. If you're going to say
that it's not a string function because you can't guarantee
the source or destination will be strings, then you may as
well say that strcpy is not a string function!
I don't recall anyone claiming that the standard C library
is a model of coherent design.
Although apparently single byte character constants being
int and not single byte characters is perfectly coherent! ;)
--
Peter
Peter Nilsson wrote:
Keith Thompson <ks...@mib.orgwrote:
....
>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.
....
>The facts that this relatively obscure data structure is
supported in the standard, that there's only one standard
function that supports it,
Huh? fread, fwrite, scanf, printf, memcpy, memcmp... to name
Neither fread() nor scanf() stops reading at a null character, nor does
either one fill the rest of a character array with null characters after
having read one. Neither fwrite() nor memcpy() stop writing at a null
character, nor does either one write extra null characters from that
point onward. memcmp() doesn't pay any special attention to null
characters. printf() can be forced to stop writing a string at a fixed
number of bytes, but the corresponding argument is still required to be
a null-terminated string, which is not guaranteed for this data
structure. Only strncpy() does these things, which makes it a very
anomalous function.
....
The function _can_ be used to copy prefixes of strings to
a string. And it _will_ terminate the destination with a
sufficiently large enough buffer. If you're going to say
that it's not a string function because you can't guarantee
the source or destination will be strings, then you may as
well say that strcpy is not a string function!
strcpy() requires that its input be a string, and guarantees, when all
of it's requirements have been met, that it's output is also a string.
>I don't recall anyone claiming that the standard C library
is a model of coherent design.
Although apparently single byte character constants being
int and not single byte characters is perfectly coherent! ;)
Well, the standard C languange isn't exactly a model of coherent design
either; it has too much history to cope with to allow that.
Flash Gordon said:
Richard Heathfield wrote, On 12/11/07 21:29:
>>
Strictly speaking, we all agree that I don't believe he doesn't make
mistakes.
OK, can we all agree that I make mistakes?
No, I think you're mistaken about that.
--
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 12, 10:00 pm, Peter Nilsson <ai...@acay.com.auwrote:
The function _can_ be used to copy prefixes of strings to
a string. And it _will_ terminate the destination with a
sufficiently large enough buffer. If you're going to say
that it's not a string function because you can't guarantee
the source or destination will be strings, then you may as
well say that strcpy is not a string function!
Hardly. If you use strcpy correctly, then you *can* guarantee that
that the source and destination will be strings. (If you do not
use it correctly you can guarantee exactly nothing, don't stop the
presses) If you use strncpy correctly then you cannot guarantee that
the source and destination will be strings.
- William Hughes
Richard Heathfield wrote:
Flash Gordon said:
>Tor Rustad wrote, On 07/11/07 01:00:
<snip>
>>>I don't think that Richard believes he is always correct.
Neither did I. ;-)
OK, we are all agree Richard makes mistakes.
Strictly speaking, we all agree that I don't believe he doesn't make
mistakes. That does not mean we all agree that I *do* make mistakes. Maybe
we do, and maybe we don't, but we haven't said so yet.
Not quite, when we agreed thinking that Richard didn't beleave he is
always correct, it did follow that we believed Richard will be wrong at
some point in space-time. When this event has occurred, Richard must
have been wrong. Either Richard was right being wrong, or Richard was
wrong believing being wrong.
OTOH, what we all believe now, might have changed, so that require a
whole new discussion. That conclude my views on the matter...
--
Tor <bw****@wvtqvm.vw | tr i-za-h a-z>
On Nov 13, 10:22 am, Tor Rustad <tor_rus...@hotmail.comwrote:
Richard Heathfield wrote:
Flash Gordon said:
Tor Rustad wrote, On 07/11/07 01:00:
<snip>
>>I don't think that Richard believes he is always correct.
Neither did I. ;-)
OK, we are all agree Richard makes mistakes.
Strictly speaking, we all agree that I don't believe he doesn't make
mistakes. That does not mean we all agree that I *do* make mistakes. Maybe
we do, and maybe we don't, but we haven't said so yet.
Not quite, when we agreed thinking that Richard didn't beleave he is
always correct, it did follow that we believed Richard will be wrong at
some point in space-time. When this event has occurred, Richard must
have been wrong. Either Richard was right being wrong, or Richard was
wrong believing being wrong.
OTOH, what we all believe now, might have changed, so that require a
whole new discussion. That conclude my views on the matter...
I remember clearly when Richard was wrong. It was when he thought
that he was mistaken. He also cut himself once, shaving with Occam's
razor. Seriously, Richard Heathfield is one of the frequent posters
to news:comp.lang.c who knows a lot about the C language. I have
learned things from Richard's posts on many occasions. He has a very
wry and dry sense of British humor that sometimes goes over everyone's
head, including mine.
I suspect that the topicality has had a wee bit of drift here. This thread has been closed and replies have been disabled. Please start a new discussion. |
