Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Bounds checking functions

Reply
Thread Tools

Bounds checking functions

 
 
Aaron Hsu
Guest
Posts: n/a
 
      02-27-2008
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 <(E-Mail Removed)>
http://www.sacrideo.us

 
Reply With Quote
 
 
 
 
Paul Hsieh
Guest
Posts: n/a
 
      02-27-2008
On Feb 26, 8:28 pm, Aaron Hsu <(E-Mail Removed)> 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.


Fundamentally, if you don't make errors in logic, you can use strcpy()
any time you can use strlcpy(). (This is the only thing some people
consider as proper -- these people live in a fantasy world where
nobody ever makes programmer errors.)

The idea of using strlcpy() or the strcpy_s() kind of things is that
be exposing the length explicitly that it will reduce the number of
errors (you can still get the length wrong by copy-paste errors, or
other errors in reasoning). This is fine, but reduction is not the
same thing as elimination. If, for example, we say that there will be
an exponentially increasing number of programs or programmers over
time, and we only reduce the number of errors by a finite percentage,
then we have done little more than bought ourselves some time before
some catastrophic bugs hit us due to a bounds overrun error.

This is the fundamental advantage to using solutions that *solve* the
problem of buffer overruns in some way or another. Bstrlib does this,
of course.

But, of course, if you believe C is a dead language, and that we are
or will soon asymptote in the number of programmers that use it, then
perhaps this is not an issue. In practice, carving percentages out of
the error scenarios, then going after the remaining one by one could
work too, since there is no longer any significant growth in the
number of C programs. I kind of doubt that the statistics on
sourceforge.net bear this assumption out just yet. Certainly C has
slowed, but I think asymptoting has not quite happened yet.

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

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      02-27-2008
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?


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.

I would consider a complete strings package like say Bstrlib a
worthwhile improvement over <string.h> and runtime bounds checking
(optional of course) as icing on the cake; the latter should be very
useful during development.

But the fact remains that C was always designed to be used by people who
are already proficient in programming. It was never designed as
a "first language" or a "teaching language" though it's practical
popularity has meant that it has been widely used in those roles too.

I would recommend that new programmers start out with something like
Java or Python and *then* pick up C or C++, even though the reverse was
true in my own case.

 
Reply With Quote
 
ymuntyan@gmail.com
Guest
Posts: n/a
 
      02-27-2008
On Feb 26, 10:28 pm, Aaron Hsu <(E-Mail Removed)> 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?


If you write some file handling stuff, what's better - corrupting
file system because your buffer is too small and you got wrong
paths, or screwing up your whole system or worse because you wrote
code like

char buf[MAX_PATH];
strcpy(buf, dir);
strcat(buf, file);

? The latter seems worse, but the real better alternative is to avoid
both, and for that you shouldn't use that infamous buf[SMART_SIZE]
in the first place. And that's the only case where "safe" functions
can really help, when you can do sizeof(buf). Otherwise, you're back
to buffer overruns. It's not as "safe" as the proposal authors make
you
think it is, by using terms like "safe" and "bounds checking". And
that's
one of the problems (the main one I think), that it's deceiving.

Yes, some people here do say that it's not hard to write correct code
in standard C, but that's a lie as their real code shows. Or science
fiction, if you wish. Safe string handling API is good, absolutely.
But don't you confuse "safe" meaning what vocabulary says, and "safe"
in the title of some paperwork

Yevgen
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      02-27-2008
santosh wrote:
> 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?

>
> 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.
>
> I would consider a complete strings package like say Bstrlib a
> worthwhile improvement over <string.h> and runtime bounds checking
> (optional of course) as icing on the cake; the latter should be very
> useful during development.
>
> But the fact remains that C was always designed to be used by people who
> are already proficient in programming. It was never designed as
> a "first language" or a "teaching language" though it's practical
> popularity has meant that it has been widely used in those roles too.
>
> I would recommend that new programmers start out with something like
> Java or Python and *then* pick up C or C++, even though the reverse was
> true in my own case.
>


That should teach you something. You started with C...
The problem santosh, as I have been telling in ALL this threads since
several ages, is that you can be a "good programmer" only 80-90%
of the time.

Since you are human, you will be always limited by the borders of your
circuit, the human circuit. This circuit can do things that computers
can't do, but it CAN'T do the things computers do, since it is a
DIFFERENT kind of circuit.

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.

This basic fact of software engineering is IGNORED by the "regulars"
here that always boast of their infallible powers.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      02-27-2008
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
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      02-27-2008
jacob navia wrote:

> santosh wrote:
>> 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?

>>
>> 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.
>>
>> I would consider a complete strings package like say Bstrlib a
>> worthwhile improvement over <string.h> and runtime bounds checking
>> (optional of course) as icing on the cake; the latter should be very
>> useful during development.
>>
>> But the fact remains that C was always designed to be used by people
>> who are already proficient in programming. It was never designed as
>> a "first language" or a "teaching language" though it's practical
>> popularity has meant that it has been widely used in those roles too.
>>
>> I would recommend that new programmers start out with something like
>> Java or Python and *then* pick up C or C++, even though the reverse
>> was true in my own case.
>>

>
> That should teach you something. You started with C...


But not for any particular reason. It just happened.

> The problem santosh, as I have been telling in ALL this threads since
> several ages, is that you can be a "good programmer" only 80-90%
> of the time.
>
> Since you are human, you will be always limited by the borders of your
> circuit, the human circuit. This circuit can do things that computers
> can't do, but it CAN'T do the things computers do, since it is a
> DIFFERENT kind of circuit.
>
> 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.
>
> This basic fact of software engineering is IGNORED by the "regulars"
> here that always boast of their infallible powers.


What you say is true. That's why we have a spectrum of languages all the
way from assembler to stuff like BASIC, JavaScript and even more
abstracted ones. It helps if the programmer knows a few selected
languages, at equidistant points along this spectrum, as in my case
which is: assembler(x86), C, C++(not really well), Java, Perl. Then he
well be able to pick the best one for the job at hand and mix and match
as desired.

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.

BTW, you often point out the large amount of downloads that your
compiler receives as indicative of the foresight of your extensions to
C, but do you actually have hard data on what fraction of lcc-win's
users actually make regular use of it's extensions to C, and not merely
use it as a compiler for ANSI C?

Do you have a document anywhere that summarises all your extensions to
ISO C and your rationale for them?

 
Reply With Quote
 
Randy Howard
Guest
Posts: n/a
 
      02-27-2008
On Wed, 27 Feb 2008 05:13:34 -0600, Richard Heathfield wrote
(in article <(E-Mail Removed)>):

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


And quite few other failures as well. Ignoring the real life aspects
of signal integrity problems in all their myriad forms, other hardware
design issues, and the complexity issues involved in platform vendors
testing all the likely hardware configurations used by their customers
with various peripherals, I/O slot population choices, etc. is putting
far too much faith in the "infallible computer". It's probably less
likely in general to make mistakes, but data corruption and other
hardware induced errors /do/ happen. There is no concept of "computers
NEVER make mistakes". That's hopelessly naive.

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


There is no language that magically corrects for the inherently
fallible nature of programming. C certainly does much less than most
other languages in this regard, but this is not a secret. No special
club membership is required to know this.

When a programmer makes the choice to use C instead of some other
language, that individual is responsible for producing the software,
finding the bugs, and eliminating them as much as possible.

If the boss tells the programmer(s) to use C, it's a slightly different
issue, but the responsibilities are much the same.

People can whine all they like about the failures of various languages,
but at the end of the day, the outcome is still that whatever language
is chosen, there will still be bugs, logic errors, misuse of APIs,
poorly tested code blocks, etc. that are an issue both during
development and post-deployment.

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.


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





 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      02-27-2008
santosh wrote:
> jacob navia wrote:
>> The problem santosh, as I have been telling in ALL this threads since
>> several ages, is that you can be a "good programmer" only 80-90%
>> of the time.
>>
>> Since you are human, you will be always limited by the borders of your
>> circuit, the human circuit. This circuit can do things that computers
>> can't do, but it CAN'T do the things computers do, since it is a
>> DIFFERENT kind of circuit.
>>
>> 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.
>>
>> This basic fact of software engineering is IGNORED by the "regulars"
>> here that always boast of their infallible powers.

>
> What you say is true. That's why we have a spectrum of languages all the
> way from assembler to stuff like BASIC, JavaScript and even more
> abstracted ones. It helps if the programmer knows a few selected
> languages, at equidistant points along this spectrum, as in my case
> which is: assembler(x86), C, C++(not really well), Java, Perl. Then he
> well be able to pick the best one for the job at hand and mix and match
> as desired.
>


But wxhy can't we make interfaces better?

Why KEEP this OLD interfaces that have proven wrong over decades?
strncpy, gets, asctime, trigraphs, all that CRUFT?


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

> BTW, you often point out the large amount of downloads that your
> compiler receives as indicative of the foresight of your extensions to
> C, but do you actually have hard data on what fraction of lcc-win's
> users actually make regular use of it's extensions to C, and not merely
> use it as a compiler for ANSI C?
>


Who knows? I do not know.

> Do you have a document anywhere that summarises all your extensions to
> ISO C and your rationale for them?
>

http://www.q-software-solutions.de/~jacob/proposal.pdf


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      02-27-2008
jacob navia wrote:

> santosh wrote:
>> jacob navia wrote:
>>> The problem santosh, as I have been telling in ALL this threads
>>> since several ages, is that you can be a "good programmer" only
>>> 80-90% of the time.
>>>
>>> Since you are human, you will be always limited by the borders of
>>> your circuit, the human circuit. This circuit can do things that
>>> computers can't do, but it CAN'T do the things computers do, since
>>> it is a DIFFERENT kind of circuit.
>>>
>>> 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.
>>>
>>> This basic fact of software engineering is IGNORED by the "regulars"
>>> here that always boast of their infallible powers.

>>
>> What you say is true. That's why we have a spectrum of languages all
>> the way from assembler to stuff like BASIC, JavaScript and even more
>> abstracted ones. It helps if the programmer knows a few selected
>> languages, at equidistant points along this spectrum, as in my case
>> which is: assembler(x86), C, C++(not really well), Java, Perl. Then
>> he well be able to pick the best one for the job at hand and mix and
>> match as desired.
>>

>
> But wxhy can't we make interfaces better?


Who said we can't. But the Committee is (understandably) slow in
proposing new stuff. Meanwhile we can still use popular de facto
standard libraries.

> Why KEEP this OLD interfaces that have proven wrong over decades?
> strncpy, gets, asctime, trigraphs, all that CRUFT?


You know very well why. For backward compatibility. To be quite honest,
more maintenance than new code development is the current situation
with C. There is a very large amount of existing software that depends
on the Standard library functions and other quirks of the language.

It's probably one reason why Stroustrup decided to create an independent
language rather than extending C and trying to force it through the
Standards process and onto all it's users, as you seem to want to do.

The problem is your proposals for interfaces depend on your extensions,
so your extensions have to first be accepted by the Committee before
your generic collections and other packages can be considered.

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


That's not purely the fault of C++ (assuming that C++ is indeed the
chief implementation language of the Visual Studio software). It's just
the Microsoft way of s/w development.

There is nothing inherently in C++ or Ada that says that s/w produced by
it must be bloated to several gigabytes. You are confusing the language
with specific software produced with it.

Can you blame English after reading one of Werty's or Wade Ward's posts?
Similarly.

>> BTW, you often point out the large amount of downloads that your
>> compiler receives as indicative of the foresight of your extensions
>> to C, but do you actually have hard data on what fraction of
>> lcc-win's users actually make regular use of it's extensions to C,
>> and not merely use it as a compiler for ANSI C?
>>

> Who knows? I do not know.


You should provide a feedback system on your website that lets lcc-win
users to anonymously post their comments and any statistics that they
want to. You might want to put up a few questionnaires. You should
probably convert to HTML and place online your tutorials to lcc-win's C
and it's benefits over ISO C.

Instead of trying to convert the Committee and this group, you probably
should improve your marketing of your compiler and try to increase the
interest of casual visitors to your site.

Oh, and also try and make your compiler portable to at least a few major
systems, other than Windows.

>> Do you have a document anywhere that summarises all your extensions
>> to ISO C and your rationale for them?
>>

> http://www.q-software-solutions.de/~jacob/proposal.pdf


Thanks.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
To increase speed on manipulating big arrays in Java with minimal bounds checking, ... Casey Hawthorne Java 16 09-01-2005 06:33 AM
Array bounds checking Chris Java 5 07-06-2005 07:23 AM
I thought that array bounds checking needed two comparisons; however, ... Casey Hawthorne Java 21 06-05-2004 08:04 PM
Bounds Checking? Julian Zhang C Programming 3 01-20-2004 11:56 PM
Macro argument bounds checking? Jim Cook C Programming 7 09-22-2003 02:50 AM



Advertisments