Bounds checking functions

[Aaron Hsu]

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 <arcfide@sacrid eo.us>

http://www.sacrideo.us

[Richard Heathfield]

Re: Bounds checking functions

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

[Randy Howard]

Re: Bounds checking functions

On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
(in article <fq3mi2$1je$1@a ioe.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

[CBFalconer]

Re: Bounds checking functions

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

[CBFalconer]

Re: Bounds checking functions

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

[CBFalconer]

Re: Bounds checking functions

Paul Hsieh wrote:

Aaron Hsu <arcf...@sacrid eo.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

[Randy Howard]

Re: Bounds checking functions

On Wed, 27 Feb 2008 10:41:03 -0600, CBFalconer wrote
(in article <47C5929F.76AD6 829@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

[jacob navia]

Re: Bounds checking functions

Randy Howard wrote:

On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
(in article <fq3mi2$1je$1@a ioe.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

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

Re: Bounds checking functions



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.

[muntyan@gmail.com]

Re: Bounds checking functions

On Feb 27, 12:25 pm, Randy Howard <randyhow...@FO OverizonBAR.net >
wrote:

On Wed, 27 Feb 2008 12:13:53 -0600, jacob navia wrote
(in article <fq4995$8f...@a ioe.org>):
>
>
>

Randy Howard wrote:

On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
(in article <fq3mi2$1j...@a ioe.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!

[jacob navia]

Re: Bounds checking functions

muntyan@gmail.c om wrote:

On Feb 27, 12:25 pm, Randy Howard <randyhow...@FO OverizonBAR.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

[Randy Howard]

Re: Bounds checking functions

On Wed, 27 Feb 2008 17:33:29 -0600, jacob navia wrote
(in article <fq4s0e$am6$1@a ioe.org>):

muntyan@gmail.c om wrote:

>On Feb 27, 12:25 pm, Randy Howard <randyhow...@FO OverizonBAR.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

[Micah Cowan]

Re: Bounds checking functions

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/

[user923005]

Re: Bounds checking functions

On Feb 27, 4:01 pm, Micah Cowan <mi...@cowan.na mewrote:

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.

[Gordon Burditt]

Re: Bounds checking functions

>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,str len(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.