473,320 Members | 1,978 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Bounds checking functions

Hey all,

After seeing the Secure version I/O functions thread, it occured to me
that maybe not everyone agrees with the almost universal adage that I
have heard. I have Always been told that using things like strlcpy and
other explicitly bounded functions were better than using the
non-bounded versions like strcpy.

Is this a matter of good programming style, or is this just needless overhead?

--
Aaron Hsu <ar*****@sacrideo.us>
http://www.sacrideo.us

Feb 27 '08 #1
27 2243
jacob navia said:

<snip>
Specifically, the human circuit is NOT able to NEVER make a mistake,
what computers ALWAYS DO. They NEVER make "mistakes", they always do
what they are told to do EXACTLY.
Not quite true. Hardware failures, cosmic rays, etc. But nevertheless
*almost* true.
This basic fact of software engineering is IGNORED by the "regulars"
here that always boast of their infallible powers.
Actually, I don't know of anyone here who claims to be infallible (except
perhaps in jest), let alone boasts about it. But you say the "regulars"
*always* boast of their infallible powers; if you are right, you will have
no trouble providing a reference to an article in which such a boast is
made.

--
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
Feb 27 '08 #2
On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
(in article <fq**********@aioe.org>):

But wxhy can't we make interfaces better?
We can. We do. You can create new interfaces independent of the std
library functions in many cases, or you can create "better" versions of
std library functions via wrappers to add safety features, or to
provide additional functionality. This has been done for ages. Open
source has to a certain degree wiped out the old commercial library
development market, but in either form, alternatives exist by the
bushel.
Why KEEP this OLD interfaces that have proven wrong over decades?
Because the legacy issue can't be gotten rid of just by snapping your
fingers. Billions (trillions?) of lines of C code are out there being
used. A lot of people love to reinvent wheels, but a lot more people
are still using the same wheels that were in use 20 years ago.
strncpy, gets, asctime, trigraphs, all that CRUFT?
You are free to not use them. Just because something exists, doesn't
mean you have to use it.
>Perhaps one reason why your posts are sometimes met with resistance is
your seeming *insistence* that C (with your embellishments) is the
*only* *viable* language for development. The fact is, no one language
has yet managed to satisfactorily address all kinds of software
development, and it's likely that that will not happen for a long time.

A simple language like C is much better than other "OO" ones.
Perhaps. The problem is, simple languages don't hold your hand. You
seem to want to take a simple language, then add features from other
languages, and pretend that it is still the simple language.

You have a compiler for this language of yours, which is based upon C,
but isn't C any longer. Why not simply come up with a new name for it,
publish a spec for it, and stop /pretending/ that it is C?

This would also allow you to eliminate all the cruft that you are
forced to carry around now, making your language "leaner and meaner",
and probably please you and perhaps others a great deal more than
whining constantly because the millions of existing C programmers don't
see it your way.

That would seem to make a lot of sense. Anyone that agrees with you
would adopt it immediately. Anyone that disagrees with you would
simply not use it. For some reason, that doesn't seem to make you
happy or you would have done so already.
A simple
software like my IDE/Debuger that installs in 30 seconds is much
EASIER TO USE than C# with Visual studio 2008 and 4GB of software!
I guess that theory that says "if you build a better mousetrap, the
world will beat a path to your door" isn't working out then? If this
was as much of a slam dunk as you claim, Microsoft would be out of the
compiler market. Clearly not everyone agrees with you.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Feb 27 '08 #3
santosh wrote:
Aaron Hsu wrote:
>After seeing the Secure version I/O functions thread, it occured
to me that maybe not everyone agrees with the almost universal
adage that I have heard. I have Always been told that using
things like strlcpy and other explicitly bounded functions were
better than using the non-bounded versions like strcpy.

Is this a matter of good programming style, or is this just
needless overhead?

I personally don't consider strlcpy or strcpy_s of much of an
improvement over strcpy and similarly for the other functions.
You still need to get the length right, and if you do get it
right, then strcpy, strcat etc. are perfectly safe.
But if you get it wrong, strlcpy/cat etc. will tell you, and not
blow up your system. They will even often tell you by how much.
Their only problem is not being in the C std library.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Feb 27 '08 #4
Randy Howard wrote:
>
.... snip ...
>
If someone knows of the magical programming language that makes
all of these issues go away, I would like to be told of it. If
there isn't one, then we'll have to continue to pick languages
based upon their appropriateness for a given task, and continue
to fix bugs.
s/all/most/

Pascal and Ada. :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Feb 27 '08 #5
Paul Hsieh wrote:
Aaron Hsu <arcf...@sacrideo.uswrote:
>After seeing the Secure version I/O functions thread, it occured
to me that maybe not everyone agrees with the almost universal
adage that I have heard. I have Always been told that using
things like strlcpy and other explicitly bounded functions were
better than using the non-bounded versions like strcpy.
.... snip erroneous evaluation of strlcpy ...
>
>Is this a matter of good programming style, or is this just
needless overhead?

Its a hack. Its not technically needed, and when it can be used
for its primary purpose its effects are partial. I don't think
the question of style or needless overhead enter into it. Its
more philosophical.
No, strlcpy and strlcat are much easier and more accurately used
that any combination of strcpy, strcat, strncpy, etc. They are a
part of the BSD system, and should be propagated into the standard
C library. You can see what they are, how they differ, and perform
your own accurate evaluation from strlcpy.zip available at:

<http://cbfalconer.home.att.net/download/>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Feb 27 '08 #6
On Wed, 27 Feb 2008 10:41:03 -0600, CBFalconer wrote
(in article <47***************@yahoo.com>):
santosh wrote:
>Aaron Hsu wrote:
>>After seeing the Secure version I/O functions thread, it occured
to me that maybe not everyone agrees with the almost universal
adage that I have heard. I have Always been told that using
things like strlcpy and other explicitly bounded functions were
better than using the non-bounded versions like strcpy.

Is this a matter of good programming style, or is this just
needless overhead?

I personally don't consider strlcpy or strcpy_s of much of an
improvement over strcpy and similarly for the other functions.
You still need to get the length right, and if you do get it
right, then strcpy, strcat etc. are perfectly safe.

But if you get it wrong, strlcpy/cat etc. will tell you, and not
blow up your system. They will even often tell you by how much.
Their only problem is not being in the C std library.
Not to mention having a name (starting with str) that is not to be used
if not in the standard. Apparently arguing about this only counts when
used by functions that folks don't think should be part of standard C,
because they get flagged over it, but for other functions, like
strlcpy() nobody seems to object.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Feb 27 '08 #7
Randy Howard wrote:
On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
(in article <fq**********@aioe.org>):

>But wxhy can't we make interfaces better?

We can. We do. You can create new interfaces independent of the std
library functions in many cases, or you can create "better" versions of
std library functions via wrappers to add safety features, or to
provide additional functionality. This has been done for ages. Open
source has to a certain degree wiped out the old commercial library
development market, but in either form, alternatives exist by the
bushel.
Then, if all that is OK, why you and the other people here are
ranting when Microsoft proposes a standard about those "wrappers"?

All functions in the microsoft proposal just add error checking to the
basic library functions.
>Why KEEP this OLD interfaces that have proven wrong over decades?

Because the legacy issue can't be gotten rid of just by snapping your
fingers. Billions (trillions?) of lines of C code are out there being
used. A lot of people love to reinvent wheels, but a lot more people
are still using the same wheels that were in use 20 years ago.
Yes. And they can go on doing that. Who cares? Nobody is
proposing to make all those functions (except the obviously
buggy ones like gets) obsolete instantaneously.

Why can't we use for NEW code better interfaces?

This is the central point of my argumentation. And it is repeated
thousand times and you ignored it AGAIN.
>strncpy, gets, asctime, trigraphs, all that CRUFT?

You are free to not use them. Just because something exists, doesn't
mean you have to use it.
>>Perhaps one reason why your posts are sometimes met with resistance is
your seeming *insistence* that C (with your embellishments) is the
*only* *viable* language for development. The fact is, no one language
has yet managed to satisfactorily address all kinds of software
development, and it's likely that that will not happen for a long time.
A simple language like C is much better than other "OO" ones.

Perhaps. The problem is, simple languages don't hold your hand. You
seem to want to take a simple language, then add features from other
languages, and pretend that it is still the simple language.
Adding the changes that I proposed makes the language

***SMALLER***.
Why that?

Because instead of having complex numbers (as standardized in C99) or
decimal numbers or fixed point numbers ALL in the language, we can
use a SINGLE extension (operator overloading) to accommodate them ALL.

That means that the language gets smaller by including a general
feature that will allow it to have ANY kind of numbers.

With the SAME feature (operator overloading) it is possible to
transparently make a bounded arrays package and use it when debugging,
and without changing a line of code you can revert to the old arrays
in production.

For instance.

Other advantages of that single change are described in my proposal
available at:

http://www.q-software-solutions.de/~jacob/proposal.pdf
You have a compiler for this language of yours, which is based upon C,
but isn't C any longer. Why not simply come up with a new name for it,
publish a spec for it, and stop /pretending/ that it is C?
It is one of the few C99 implementations under windows. Done with
years of effort from my part. But here I have to hear from people
that never have done anything to promote standard C that "It is not C"

At least CB Falconer proposes his strlcpy or ggets packages.

What do YOU propose Mr Howard?

Just empty talk.

Easy isn't it?
[crap elided]

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Feb 27 '08 #8


Aaron Hsu wrote:
Hey all,

After seeing the Secure version I/O functions thread, it occured to me
that maybe not everyone agrees with the almost universal adage that I
have heard. I have Always been told that using things like strlcpy and
other explicitly bounded functions were better than using the
non-bounded versions like strcpy.

Is this a matter of good programming style, or is this just needless overhead?

In my opinion, this depends entirely upon two things:

1) The competency of the programmer
2) The programmer's view of their own competency

For instance, I myself have high confidence in my own programming and
so I feel comfortable playing around with pointers. I don't have a
need for bounds checking, so any overhead introduced by bounds
checking would seem unacceptable to me.

In debug mode tho, I usually have all the warnings and safeguards
cranked thru the roof.
Feb 27 '08 #9
On Feb 27, 12:25 pm, Randy Howard <randyhow...@FOOverizonBAR.net>
wrote:
On Wed, 27 Feb 2008 12:13:53 -0600, jacob navia wrote
(in article <fq4995$8f...@aioe.org>):
Randy Howard wrote:
On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
(in article <fq3mi2$1j...@aioe.org>):
>But wxhy can't we make interfaces better?
We can. We do. You can create new interfaces independent of the std
library functions in many cases, or you can create "better" versions of
std library functions via wrappers to add safety features, or to
provide additional functionality. This has been done for ages. Open
source has to a certain degree wiped out the old commercial library
development market, but in either form, alternatives exist by the
bushel.
Then, if all that is OK, why you and the other people here are
ranting when Microsoft proposes a standard about those "wrappers"?

When did I rant about a Microsoft proposal? A simple link will do.
All functions in the microsoft proposal just add error checking to the
basic library functions.

Then why not just introduce them as an open source library that
provides these wrappers? If they wanted them to be widely adopted and
quickly, this would be out there. Where can this library be
downloaded?
Good one!
Feb 27 '08 #10
mu*****@gmail.com wrote:
On Feb 27, 12:25 pm, Randy Howard <randyhow...@FOOverizonBAR.net>
wrote:
>On Wed, 27 Feb 2008 12:13:53 -0600, jacob navia wrote
>>All functions in the microsoft proposal just add error checking to the
basic library functions.
>Then why not just introduce them as an open source library that
provides these wrappers? If they wanted them to be widely adopted and
quickly, this would be out there. Where can this library be
downloaded?
>
Good one!
lcc-win implemented most of it. I could put this in the public
domain.

The safe string library from microsoft, was open source.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Feb 27 '08 #11
On Wed, 27 Feb 2008 17:33:29 -0600, jacob navia wrote
(in article <fq**********@aioe.org>):
mu*****@gmail.com wrote:
>On Feb 27, 12:25 pm, Randy Howard <randyhow...@FOOverizonBAR.net>
wrote:
>>On Wed, 27 Feb 2008 12:13:53 -0600, jacob navia wrote
All functions in the microsoft proposal just add error checking to the
basic library functions.
>>Then why not just introduce them as an open source library that
provides these wrappers? If they wanted them to be widely adopted and
quickly, this would be out there. Where can this library be
downloaded?
>>
Good one!

lcc-win implemented most of it. I could put this in the public
domain.

The safe string library from microsoft, was open source.
Oh good, the problem is solved then. So why are you complaining about
it?

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Feb 27 '08 #12
William Ahern wrote:
Knuth and Berstein haven't written many checks.
http://en.wikipedia.org/wiki/Knuth_reward_check

....As of March 2005, the total value of the checks signed by Knuth was
over $20,000...

Still, the fact that he's confident enough to offer the cash reward in
the first place is a pretty big deal.

I agree with Yevgen's general point that it is far too difficult to
write correct C programs. Even doing it 80-90% of the time, as most
regulars here can probably manage, is itself a noteworthy accomplishment.

I think that part of being a good programmer, then, is to limit the
opportunities you have to make those mistakes. Set up frameworks to do
all the "good habit" stuff for you, so that you don't have to be
constantly avoiding "bad habit" stuff yourself (if you have to avoid a
mistake 999 times, the 1000th time you may fail to avoid it). This is
why, when it matters, many programs and packages will use their own
string-handling frameworks that do exactly that. The better you
encapsulate/hide away the details of managing buffer sizes, resizing,
concatenation, comparison, etc, the more you can focus on doing other
things.

All that being said, I fail to see how strlcpy() or strcpy_s() help the
matter much. They aren't appreciably easier to use correctly, by which I
mean that they are approximately as prone to "bad habit" problems as
strcpy() is. They certainly don't hide the details of managing buffer
sizes, and you still have that opportunity to mess up on that 1000th
time you use it. And I certainly resent being told otherwise, in the
form of silly linker diagnostics, when I choose to use the more standard
of these all-unsafe facilities.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Feb 28 '08 #13
On Feb 27, 4:01*pm, Micah Cowan <mi...@cowan.namewrote:
William Ahern wrote:
Knuth and Berstein haven't written many checks.

http://en.wikipedia.org/wiki/Knuth_reward_check

...As of March 2005, the total value of the checks signed by Knuth was
over $20,000...

Still, the fact that he's confident enough to offer the cash reward in
the first place is a pretty big deal.

I have a check from Knuth for $2.88 and it is one of my most prized
posessions. I have it framed, and it sits over my desk at work.
I agree with Yevgen's general point that it is far too difficult to
write correct C programs. Even doing it 80-90% of the time, as most
regulars here can probably manage, is itself a noteworthy accomplishment.

I think that part of being a good programmer, then, is to limit the
opportunities you have to make those mistakes. Set up frameworks to do
all the "good habit" stuff for you, so that you don't have to be
constantly avoiding "bad habit" stuff yourself (if you have to avoid a
mistake 999 times, the 1000th time you may fail to avoid it). This is
why, when it matters, many programs and packages will use their own
string-handling frameworks that do exactly that. The better you
encapsulate/hide away the details of managing buffer sizes, resizing,
concatenation, comparison, etc, the more you can focus on doing other
things.
I think that things that could be done to make C safer are probably a
good idea in the long run. Who doesn't want to remove gets() from C?
All that being said, I fail to see how strlcpy() or strcpy_s() help the
matter much. They aren't appreciably easier to use correctly, by which I
mean that they are approximately as prone to "bad habit" problems as
strcpy() is. They certainly don't hide the details of managing buffer
sizes, and you still have that opportunity to mess up on that 1000th
time you use it. And I certainly resent being told otherwise, in the
form of silly linker diagnostics, when I choose to use the more standard
of these all-unsafe facilities.
I think that software reuse is one of the better ways to reduce
defects. That is because:
1. The product is probably debugged fairly well in the first place if
you are reusing it.
2. Using a tool in a variety of settings tends to increase the
robustness because it gets tested even more thoroughly.

In C, the primary method of reuse is the library.
Feb 28 '08 #14
>After seeing the Secure version I/O functions thread, it occured to me
>that maybe not everyone agrees with the almost universal adage that I
have heard. I have Always been told that using things like strlcpy and
other explicitly bounded functions were better than using the
non-bounded versions like strcpy.
strlcpy() is not a solution to all the world's problems. A mandate
to use it instead of strcpy() will likely result in some lazy
programmer doing something like:

#define strcpy(d,s) strlcpy(d,s,strlen(s))

which just keeps all the problems of using strcpy().

And if you've already length-checked your input (along with whatever
else is required, like checking it against a regular expression,
removing extraneous blanks, verifying a valid area code, spell-checking
it, rejecting submissions with bad 4-letter words (like "RIAA" or
"Gore"), etc.), using strlcpy() is just redundant and likely
inefficient.

Feb 28 '08 #15
Gordon Burditt wrote:
>
.... snip ...
>
strlcpy() is not a solution to all the world's problems. A
mandate to use it instead of strcpy() will likely result in some
lazy programmer doing something like:

#define strcpy(d,s) strlcpy(d,s,strlen(s))

which just keeps all the problems of using strcpy().
Please avoid stripping attributions.

No, the lazy programmer can't do that. strcpy returns s. strlcpy
returns the string length strlcpy attempted to create. If it is
less than the strlen(s) parameter above, all is well. Otherwise
you know exactly how big a string object is needed. Same for
strlcat.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Feb 28 '08 #16
Micah Cowan wrote:
>
.... snip ...
>
In short, I rarely want to truncate, and when I _do_, I rarely
want to do it naively (as strlcat() will do).

I'm not against its inclusion, I just think its utility has
been _way_ overblown.
And what is the better result? If you want to remove the leading
part of the output string, you can do that. If you want to provide
a larger buffer, you can do that. If you want to truncate, you
already did that.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Feb 28 '08 #17
CBFalconer wrote:
Micah Cowan wrote:
... snip ...
>In short, I rarely want to truncate, and when I _do_, I rarely
want to do it naively (as strlcat() will do).

I'm not against its inclusion, I just think its utility has
been _way_ overblown.
(I had actually meant strlcpy(), there, but the same applies to strlcat().)
And what is the better result? If you want to remove the leading
part of the output string, you can do that.
Which is no different from what already exists.
If you want to provide
a larger buffer, you can do that.
Which is no different from what already exists. Except that, with
strlcpy(), I've wasted time copying to a buffer I didn't want to copy
into in the first place.
If you want to truncate, you
already did that.
As I've already indicated, and you quoted, I have never _wanted_ to do
that, and of the times I might want to do that, it's likely I may not
wish to do it the way strlcpy() does.

"If I don't want to truncate, I..." oh. Well I'm SOL.

Look, what do I care if you like it, find it useful, and want to use it?
I don't, and I think I've made more than a strong enough case to
justify arguing in my previous post that insisting I should is awfully
presumptuous.

And if insisting that I find it useful is presumptuous, then demanding
that I use it in all cases in preference over strcpy() (which, recall,
is the topic of this discussion) is hopelessly deluded.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Feb 28 '08 #18
Micah Cowan said:
William Ahern wrote:
>Knuth and Berstein haven't written many checks.

http://en.wikipedia.org/wiki/Knuth_reward_check

...As of March 2005, the total value of the checks signed by Knuth was
over $20,000...
My own cheque is for $2.56. If that's average (some are for more, and some
for less), then that's about 8000 cheques over, what, forty years? Around
200 mistakes a year - fewer than one per day. If we count that as an error
metric, then, I'd call it "very few". Who else amongst us can make so few
mistakes?
Still, the fact that he's confident enough to offer the cash reward in
the first place is a pretty big deal.
Right!
I agree with Yevgen's general point that it is far too difficult to
write correct C programs. Even doing it 80-90% of the time, as most
regulars here can probably manage, is itself a noteworthy accomplishment.
It's probably truer to say that it's difficult to write correct programs,
no matter what the language. C is pretty simple as languages go.

<snip>

--
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
Feb 28 '08 #19
On 28 Feb, 01:13, user923005 <dcor...@connx.comwrote:
On Feb 27, 4:01*pm, Micah Cowan <mi...@cowan.namewrote:
William Ahern wrote:
Knuth and Berstein haven't written many checks.
<snip>
I agree with Yevgen's general point that it is far too difficult to
write correct C programs. Even doing it 80-90% of the time, as most
regulars here can probably manage, is itself a noteworthy accomplishment..
I think that part of being a good programmer, then, is to limit the
opportunities you have to make those mistakes. Set up frameworks to do
all the "good habit" stuff for you, so that you don't have to be
constantly avoiding "bad habit" stuff yourself (if you have to avoid a
mistake 999 times, the 1000th time you may fail to avoid it). This is
why, when it matters, many programs and packages will use their own
string-handling frameworks that do exactly that. The better you
encapsulate/hide away the details of managing buffer sizes, resizing,
concatenation, comparison, etc, the more you can focus on doing other
things.

I think that things that could be done to make C safer are probably a
good idea in the long run. *Who doesn't want to remove gets() from C?
as I don't use get() I don't care.

All that being said, I fail to see how strlcpy() or strcpy_s() help the
matter much. They aren't appreciably easier to use correctly, by which I
mean that they are approximately as prone to "bad habit" problems as
strcpy() is. They certainly don't hide the details of managing buffer
sizes, and you still have that opportunity to mess up on that 1000th
time you use it. And I certainly resent being told otherwise, in the
form of silly linker diagnostics, when I choose to use the more standard
of these all-unsafe facilities.
me too
I think that software reuse is one of the better ways to reduce
defects. *
http://en.wikipedia.org/wiki/Ariane_5_Flight_501
:-)

That is because:
1. *The product is probably debugged fairly well in the first place if
you are reusing it.
2. *Using a tool in a variety of settings tends to increase the
robustness because it gets tested even more thoroughly.

In C, the primary method of reuse is the library.
yes, great. All apple pie and motherhood. What does this have to
do with strlcpy() or strcpy_s()?
--
Nick Keighley

"To every complex problem there is a simple solution... and it is
wrong."
-- Turski
Feb 28 '08 #20
On Thu, 28 Feb 2008 01:53:26 -0600, Richard Heathfield wrote
(in article <ws******************************@bt.com>):
Micah Cowan said:
>William Ahern wrote:
>>Knuth and Berstein haven't written many checks.

http://en.wikipedia.org/wiki/Knuth_reward_check

...As of March 2005, the total value of the checks signed by Knuth was
over $20,000...

My own cheque is for $2.56. If that's average (some are for more, and some
for less), then that's about 8000 cheques over, what, forty years? Around
200 mistakes a year - fewer than one per day. If we count that as an error
metric, then, I'd call it "very few". Who else amongst us can make so few
mistakes?
>Still, the fact that he's confident enough to offer the cash reward in
the first place is a pretty big deal.

Right!
It's also a very low expense over all those years for hiring a large
number of very dedicated reviewers. That, or he wanted to make sure
people paid attention for that reason alone. Either way, it was and
remains highly effective.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Feb 28 '08 #21
Micah Cowan wrote:
CBFalconer wrote:
>Micah Cowan wrote:

... snip ...
>>In short, I rarely want to truncate, and when I _do_, I rarely
want to do it naively (as strlcat() will do).

I'm not against its inclusion, I just think its utility has
been _way_ overblown.

(I had actually meant strlcpy(), there, but the same applies to
strlcat().)
>And what is the better result? If you want to remove the
leading part of the output string, you can do that.

Which is no different from what already exists.
Yes it is different. strcpy and strcat will write to unowned
memory, and blow something else up. strncpy will not always
terminate the string correctly, and will always waste time zero
filling. Also their return value is different. Note that strlcpy
and strlcat return the size of string they attempted to create, not
a char*, and that you decide about success by comparing that return
with the length you told them they had available.
>
>If you want to provide a larger buffer, you can do that.

Which is no different from what already exists. Except that,
with strlcpy(), I've wasted time copying to a buffer I didn't
want to copy into in the first place.
>If you want to truncate, you already did that.

As I've already indicated, and you quoted, I have never _wanted_
to do that, and of the times I might want to do that, it's
likely I may not wish to do it the way strlcpy() does.

"If I don't want to truncate, I..." oh. Well I'm SOL.
Not if you use strlcpy/cat. Then you find out things didn't fit,
and the size needed to allow them to fit.
>
Look, what do I care if you like it, find it useful, and want to
use it? I don't, and I think I've made more than a strong enough
case to justify arguing in my previous post that insisting I
should is awfully presumptuous.
Nobody is insisting on anything. Your posts indicate that you have
missed some of the advantages available. I am trying to fill in
those gaps.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

Feb 28 '08 #22
CBFalconer <cb********@yahoo.comwrote:
Micah Cowan wrote:
In short, I rarely want to truncate, and when I _do_, I rarely
want to do it naively (as strlcat() will do).

I'm not against its inclusion, I just think its utility has
been _way_ overblown.

And what is the better result?
I don't know, but I bet it can be achieved by using the perfectly
Standard strncat().

Richard
Feb 28 '08 #23
CBFalconer wrote:
Micah Cowan wrote:
>CBFalconer wrote:
>>Micah Cowan wrote:

... snip ...

In short, I rarely want to truncate, and when I _do_, I rarely
want to do it naively (as strlcat() will do).

I'm not against its inclusion, I just think its utility has
been _way_ overblown.
(I had actually meant strlcpy(), there, but the same applies to
strlcat().)
>>And what is the better result? If you want to remove the
leading part of the output string, you can do that.
Which is no different from what already exists.

Yes it is different. strcpy and strcat will write to unowned
memory, and blow something else up.
If you abuse it. Which has nothing to do with what I said was not
different (the ability to remove a leading part of the output string),
and yet, is _still_ not different, anyway, as strlcpy() is also quite
capable of the same thing.
>>If you want to provide a larger buffer, you can do that.
Which is no different from what already exists. Except that,
with strlcpy(), I've wasted time copying to a buffer I didn't
want to copy into in the first place.
>>If you want to truncate, you already did that.
As I've already indicated, and you quoted, I have never _wanted_
to do that, and of the times I might want to do that, it's
likely I may not wish to do it the way strlcpy() does.

"If I don't want to truncate, I..." oh. Well I'm SOL.

Not if you use strlcpy/cat. Then you find out things didn't fit,
and the size needed to allow them to fit.
And that I wasted plenty of valuable time. And: whoa! strlen() already
does that, without the useless copy.
>Look, what do I care if you like it, find it useful, and want to
use it? I don't, and I think I've made more than a strong enough
case to justify arguing in my previous post that insisting I
should is awfully presumptuous.

Nobody is insisting on anything.
If your statement were correct, this thread would not have been started.
Please go back to the OP and read it. That _is_ the basis of this thread
(perhaps you're confusing it with the *_s() one?).
Your posts indicate that you have
missed some of the advantages available. I am trying to fill in
those gaps.
Since you have still failed to name a single advantage over
strlen()+strcpy() (and seem to be deliberately ignoring several
disadvantages), I'd say you haven't done that.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Feb 28 '08 #24
Randy Howard wrote:
On Thu, 28 Feb 2008 01:53:26 -0600, Richard Heathfield wrote
>>Still, the fact that he's confident enough to offer the cash reward in
the first place is a pretty big deal.
Right!

It's also a very low expense over all those years for hiring a large
number of very dedicated reviewers. That, or he wanted to make sure
people paid attention for that reason alone. Either way, it was and
remains highly effective.
All the lower, considering the majority of them are never cashed.
Heathfield, certainly, was not dumb enough to cash his. :)

That'd be akin to selling an olympic medal, only one that's worth a mere
$0x100.

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
Feb 28 '08 #25
Micah Cowan <mi***@cowan.namewrote:
CBFalconer wrote:
Micah Cowan <mi***@cowan.namewrote:
<snip>
Not if you use strlcpy/cat. Then you find out things didn't fit,
and the size needed to allow them to fit.

And that I wasted plenty of valuable time. And: whoa! strlen() already
does that, without the useless copy.
Not entirely true. realloc() might preserve the block, and its copy might be
faster (in cache) than copying to a new block. In any event, this cost would
can be amoritized. As opposed to a pattern which necessitates _two_
iterations over the string, always, without any potential to reduce work.

If you just wanted to use strlen(), then use strlen()+memcpy().
strlen()+strcpy() is superfluous.
Look, what do I care if you like it, find it useful, and want to
use it? I don't, and I think I've made more than a strong enough
case to justify arguing in my previous post that insisting I
should is awfully presumptuous.
Nobody is insisting on anything.
If your statement were correct, this thread would not have been started.
Please go back to the OP and read it. That _is_ the basis of this thread
(perhaps you're confusing it with the *_s() one?).
I sort of figured this had evolved into a sub-thread.
Your posts indicate that you have
missed some of the advantages available. I am trying to fill in
those gaps.
Since you have still failed to name a single advantage over
strlen()+strcpy() (and seem to be deliberately ignoring several
disadvantages), I'd say you haven't done that.
The extra N conditionals. With strlen()+strcpy(), you're still checking for
NUL every character. If you _already_ know the length, why not use memcpy()?

Only place I can imagine using strcpy() is when I know the source buffer is
less than or equal to the destination buffer, and I'm happy to _discard_ the
length which is derived in the process of copying the string. But a standard
function which _discards_ information has a flaw, IMO. A user should be free
to ignore it, but its a poor tool that makes it impossible without
duplicating work.

Feb 28 '08 #26
William Ahern <wi*****@wilbur.25thandclement.comwrote:
Micah Cowan <mi***@cowan.namewrote:
CBFalconer wrote:
>Micah Cowan <mi***@cowan.namewrote:
<snip>
Not if you use strlcpy/cat. Then you find out things didn't fit,
and the size needed to allow them to fit.
And that I wasted plenty of valuable time. And: whoa! strlen() already
does that, without the useless copy.
Not entirely true. realloc() might preserve the block, and its copy might be
faster (in cache) than copying to a new block. In any event, this cost would
That doesn't really make any sense. Please ignore. ;)

Feb 28 '08 #27
On Wed, 27 Feb 2008 11:45:38 -0500, CBFalconer <cb********@yahoo.com>
wrote:
Randy Howard wrote:
... snip ...

If someone knows of the magical programming language that makes
all of these issues go away, I would like to be told of it. If
there isn't one, then we'll have to continue to pick languages
based upon their appropriateness for a given task, and continue
to fix bugs.

s/all/most/

Pascal and Ada. :-)
Smiley notwithstanding, those languages do nothing to prevent logic
errors, and don't prevent poor testing, although they can reduce
somewhat the amount of testing needed and thus make it easier.They do
prevent _some_ interface misuses (I hate calling everything an API)
that can be expressed by a relatively rich type system. Eiffel goes
further by allowing arbitrary constraints, but even that has limits:
if the conditions get too complicated, they not only hurt performance,
but become confusing, errorprone, and unreliable themselves.

The one thing robust (aka S&M) languages do (or at least can) that I
consider valuable is enforce high-level semantics. IME&O the most
troublesome bugs in C (and now-few similar languages) is what I call
'low to high leakage'. If you just have a wrong computation, or
condition, or value, it's easy enough to see in the source
(preprocessed if necessary) once you know what to look for/at.
But if you store through a wild pointer (including stale, and
subscript out of range) it can cause failures in a part of the program
that looks and is correct on its own and according to the defined
semantics should be completely separate. A robust language can force
the fault into a part of the source that is relevant. That's a real
benefit, not to be sneezed at in my book; but it is not the solution
to everything. <offtopic42 is, of course. </>

- formerly david.thompson1 || achar(64) || worldnet.att.net
Mar 10 '08 #28

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

50
by: jacob navia | last post by:
As everybody knows, the C language lacks a way of specifying bounds checked arrays. This situation is intolerable for people that know that errors are easy to do, and putting today's powerful...
22
by: jacob navia | last post by:
A function like strcpy takes now, two unbounded pointers. Unbounded pointers, i.e. pointers where there is no range information, have catastrophic failure modes specially when *writing* to main...
125
by: jacob navia | last post by:
We hear very often in this discussion group that bounds checking, or safety tests are too expensive to be used in C. Several researchers of UCSD have published an interesting paper about this...
7
by: polas | last post by:
Afternoon everyone. I have a quick question about standard C. Generally speaking, in my experience, whenever one accesses an array there is never any bounds checking done (either statically...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.