Bounds checking functions
Aaron Hsu
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 <arc...@sacrideo.us>
http://www.sacrideo.us
Paul Hsieh
> 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/
santosh
> 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.
ymun...@gmail.com
> 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
jacob navia
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
Richard Heathfield
<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
santosh
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?
Randy Howard
(in article <zZmdnQEEqI5u2Vja...@bt.com>):
> 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
jacob navia
> 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
santosh
> 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.
Randy Howard
(in article <fq3mi2$1je$1...@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.
CBFalconer
> Aaron Hsu wrote:
>
>> 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
>
... 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. :-)
CBFalconer
> Aaron Hsu <arcf...@sacrideo.us> 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?
>
> 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/>
Randy Howard
(in article <47C5929F...@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.
jacob navia
> On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
> (in article <fq3mi2$1je$1...@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]
Tomás Ó hÉilidhe
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.
Randy Howard
(in article <fq4995$8fu$1...@aioe.org>):
> Randy Howard wrote:
>> On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
>> (in article <fq3mi2$1je$1...@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?
>>> 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?
You are free to do so. The problem seems to lie in you wanting to make
everyone do it your way, and you get quite pissy about it when that
doesn't happen.
> This is the central point of my argumentation. And it is repeated
> thousand times and you ignored it AGAIN.
I didn't ignore it. If anything, I said it myself. Read my first
paragraph above.
>>> 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?
Painful grammar notwithstanding, you don't get to make the language
smaller unless you want to break legacy code, which you said about that
you do not intend to do. You need to pick one answer, and stick with
it.
> 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.
There are more than zero programmers that strongly dislike operator
overloading for a variety of reasons. There are languages that include
it already though, so if you want such, use one of them, or create a
new one.
> 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.
Only one problem here. C does not have operator overloading.
> Other advantages of that single change are described in my proposal
> available at:
>
> http://www.q-software-solutions.de/~jacob/proposal.pdf
Yes, I've read it.
>> 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.
It's quite a bit different from a pure C99 implementation though, isn't
it? You are on record as being far less than happy with standard C in
any of its versions, but correct me if I misinterpreted you on this
point.
> But here I have to hear from people that never have done anything to
> promote standard C that "It is not C"
Why does standard C need promoting? If anything, more than enough
people use it already.
> At least CB Falconer proposes his strlcpy or ggets packages.
>
> What do YOU propose Mr Howard?
I am quite happy with the language available as C89, and have not
perceived a need for anything more than that in order to use C
effectively.
> [crap elided]
So you call the notion of you creating a new language that embodies all
of the ideas that you find worthwhile under a new name to be crap?
Well, I might agree with you, but probably not for the reasons you
might guess.
William Ahern
>
<snip>
> 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).
This scenario accounts for the vast majority of cases where I handle
"strings". 8, 64, 255, 1024; these are magic numbers that litter innumerable
RFCs and other standards. In many cases its possible to be given input which
doesn't fit the constraint, and often its OK to reject the input. But, point
being, I size char buffers in structures using these values. Having a
statically sized buffer of 64 or 255 bytes, or even 1024, is usually easier
and faster and, probably, safer than dynamically managing that particular
piece of memory. All things being equal, less code is safer code.
Now, much of the time I already know the size of the input before copying.
But there are often cases where the design has an [intentional] gap, and
you're passed a string without a size, often at the junction where a library
or component exposes itself to code usage which expects a more canonical
string interface--just a pointer. In such instances, strlcpy is priceless.
The utility of strlcpy is tacitly recognized and reflected in the signature
of C99's snprintf.
<snip>
> 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.
I agree. Particularly the notion that "bounds checking" is some sort of
exceptional or uncharacteristic quality of general programming hygiene.
These new interfaces certainly don't do bounds checking for you. They merely
alleviate a small part of the burden in some circumstances.
> 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.
Well... lie or not, it's something to aspire to. That sort of defeatist (as
opposed to pragmatic) attitude can't be helpful. Certainly it sounds a bit
presumptive. Knuth and Berstein haven't written many checks. It goes without
saying that nobody's perfect, though.
> 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 ;)
The same goes for "security", or the myriad other amorphous qualitative
terms. There'll never be a substitute for critical reading and analysis. Yet
discerning writers and readers continue to use the term, because its not
their job to cater to the least common denominator, but rather to
efficiently get their message across to their intended audience.
Notwithstanding hyperbole and rhetoric, when a writer uses the term, it
_signals_ to the reader how he should approach the writing or claim.
CBFalconer
> Randy Howard wrote:
>
... snip ...
>
>> 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.
I want to popularize those routines. If they become sufficiently
popular, they may get included in a future version of the C
standard. Meanwhile everybody has access to them. That is why
they are in the public domain. And it is not 'my' strlcpy, just my
implementation.
Note that hashlib is not in the public domain. It is released
under GPL. I consider it a first class solution to the problem;
others may not. For other things you will have to examine the
releases, but they will be either public or GPL.
CBFalconer
> CBFalconer wrote
>
... snip ...
>
>> 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.
My release has documentation mentioning that problem, and what to
do to comply.
mun...@gmail.com
wrote:
> ymunt...@gmail.com wrote:
>
> <snip>
> > 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).
>
> This scenario accounts for the vast majority of cases where I handle
> "strings". 8, 64, 255, 1024; these are magic numbers that litter innumerable
> RFCs and other standards. In many cases its possible to be given input which
> doesn't fit the constraint, and often its OK to reject the input. But, point
> being, I size char buffers in structures using these values. Having a
> statically sized buffer of 64 or 255 bytes, or even 1024, is usually easier
> and faster and, probably, safer than dynamically managing that particular
> piece of memory. All things being equal, less code is safer code.
>
> Now, much of the time I already know the size of the input before copying.
> But there are often cases where the design has an [intentional] gap, and
> you're passed a string without a size, often at the junction where a library
> or component exposes itself to code usage which expects a more canonical
> string interface--just a pointer. In such instances, strlcpy is priceless.
I guess if you do have a fixed size buffer, then yes, you want to be
sure
you don't write more than its size. But I doubt there are many cases
where
you can do with a fixed size buffer. For example: MAX_PATH has bogus
value at least on one major implementation, and so you can't have
MAX_PATH
as an upper bound for filename length. Or LINE_MAX - won't work on
windows
with a file which has unix line endings (and so *user* will have to
fix it).
But I don't have much experience in different domains, and YMMV.
>
> The utility of strlcpy is tacitly recognized and reflected in the signature
> of C99's snprintf.
>
> <snip>
>
> > 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.
>
> I agree. Particularly the notion that "bounds checking" is some sort of
> exceptional or uncharacteristic quality of general programming hygiene.
>
> These new interfaces certainly don't do bounds checking for you. They merely
> alleviate a small part of the burden in some circumstances.
>
> > 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.
>
> Well... lie or not, it's something to aspire to. That sort of defeatist (as
> opposed to pragmatic) attitude can't be helpful.
Um, I believe it's perfectly pragmatic attitude that it's hard to
write
correct code. Programming is hard. It's not defeatist. Defeatist is
saying
"I won't write correct code anyway, so I'll be as careless as I like".
> Certainly it sounds a bit
> presumptive. Knuth and Berstein haven't written many checks. It goes without
> saying that nobody's perfect, though.
Note that I said two things there: "here" and "not hard".
If you quote Knuth saying in comp.lang.c how it's not hard
to write programs which handle strings in C (that is, write
correct code), I'll take my words back ;)
Yevgen
mun...@gmail.com
wrote:
> On Wed, 27 Feb 2008 12:13:53 -0600, jacob navia wrote
>
>
>
> > Randy Howard wrote:
> >> On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
>
> >>> 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
> On Feb 27, 12:25 pm, Randy Howard <randyhow...@FOOverizonBAR.net>
> wrote:
>> On Wed, 27 Feb 2008 12:13:53 -0600, jacob navia wrote
>>> 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.
Randy Howard
(in article <fq4s0e$am6$1...@aioe.org>):
> mun...@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?
Micah Cowan
> 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/
William Ahern
> 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...
But how many of those are for MiX and other errors in his books? I meant to
refer to things like TeX, parts of which are written in C.
> 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.
But I fail to see how that's an argument _against_ including an interface
like strlcpy?
Writing a "hello world" program is harder in C than in Borne Shell, and
harder still in an assembly language.
On the flip side, in a simple "hello world" program string handling doesn't
predominate, and you may very well have persuasive reasons for writing it in
C than in Borne Shell.
> 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 agree. strlcpy(), though, fills in inevitable gaps between the standard
interfaces, traditional string handling, and whatever design or manner of
approaching the issue one takes. Seems to me that's as good a reason as any
to include strlcpy(). On top of the fact, and more to the point, that it
encapsulates the _minimal_ exact code one would normally and rightly employ
in these situations.
> 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.
That's an impossible criterion. No C library, IMO, can hide the details of
buffer (aka memory, aka resource) management in C, and it's not clear to me
that off-by-ones are substantially more of an issue than NULL or dangling
pointers. They can only grease the wheels, so to speak. That is, better
weave the patterns into your code. Encapsulation being one important way to
accomplish that. But there are many levels of encapsulation, and many/most
string libraries force you to too high a level of encapsulation for what its
worth in many instances; rather than encapsulate they obsfuscate.
user923005
Have you ever heard of MTBF?
http://www.computerhope.com/jargon/m/mtbf.htm
Disks have MTBF, memory has MTBF, CPUs have MTBF. Each and every
component in the computer that produces calculations eventually
fails. Sometimes the mistakes are caught and corrected (e.g. Reed-
Solomon algorithm). Sometimes the mistakes can be caught but not
repaired. And sometimes the mistakes are not even caught.
And let's not forget the Pentium fiasco:
http://www.ddj.com/184410254
user923005
> 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
>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.
Micah Cowan
> Micah Cowan <mi...@cowan.name> wrote:
>> 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...
>
> But how many of those are for MiX and other errors in his books? I meant to
> refer to things like TeX, parts of which are written in C.
Are they? I don't think he wrote any of TeX at all in C. He wrote it all
in Pascal (or, to be more accurate, he wrote it in WEB, which compiles
to Pascal).
The resulting Pascal, these days, is generally fed to a program that
compiles _that_ to C. Parts of TeTex may have been written in CWEB,
maybe, but not by him.
(I didn't mean any of that to imply that it's safer _because_ he wrote
it in Pascal rather than C, I was just disputing whether it was the case.)
>> 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.
>
> Writing a "hello world" program is harder in C than in Borne Shell, and
> harder still in an assembly language.
>
> On the flip side, in a simple "hello world" program string handling doesn't
> predominate, and you may very well have persuasive reasons for writing it in
> C than in Borne Shell.
I don't think anyone was talking about how much work it might be to code
in C. What we were talking about was how hard it is to code _safely_ in
C. It's an entirely different question. I don't think a "Hello world"
program's safety is appreciably harder to achieve in C than it is in sh.
More complex programs are a different issue.
And of course there are reasons for choosing C over other implementation
platforms (if that weren't the case, would I be a C programmer? :) ).
>> 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 agree. strlcpy(), though, fills in inevitable gaps between the standard
> interfaces, traditional string handling, and whatever design or manner of
> approaching the issue one takes. Seems to me that's as good a reason as any
> to include strlcpy(). On top of the fact, and more to the point, that it
> encapsulates the _minimal_ exact code one would normally and rightly employ
> in these situations.
Well, no, it doesn't. strcpy() plus a buffer check does. strlcpy() adds
one more thing: copying what it can of src to dst, regardless of whether
there was enough space for all of it, or whether that's what was wanted.
This has _never_ been what I want (usually, like Yevgen, I want to
allocate more space). I can't say it will never _be_ what I want, and I
know it's sometimes what others (apparently, including yourself) have
needed. Constrained by output limits is a legitimate case. Constrained
by input limits, IMO isn't a good one ("be liberal in what you accept").
Even with your example of RFC limits, most such limits are within the
context of mechanisms that provide ways to represent entities that do
not match those constraints. For instance, if I need to force arbitrary
text files to meet the constraints of RFC 2822, I may be using a fixed
line-buffer size, but I'm sure as hell not using strlcpy() to meet that
constraint. I'd be using quoted-printable or somesuch, instead.
And even if I'm writing an old-style tarfile with fixed block sizes and
a maximum filename length, I'd _still_ probably want to ensure I
generate a unique filename, rather than blindly truncating it.
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 none of this has anything to do with the OP's actual question, which
was whether he'd been misled when people told him to always use
strlcpy() in preference to strcpy(). To which the answer, hopefully
obvious by now, is _yes_, he was misled. The utility of strcpy() is
_far_ more general than that of strlcpy().
And, while strlcpy() may be better than strcpy() for those limited
situations where you want a naive truncation (and don't mind its limited
portability), I don't see any basis for the claim that strlcpy() is
_safer_ than strcpy() (which, after all, is the basis for the claim that
you should always use it in preference to strcpy()). It is precisely as
easy to remember to use strlcpy() instead of strcpy(), as it is to
remember to check the buffer size before you strcpy() (the latter,
though, still gives you more options about what to do after the check
fails).
>> 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.
>
> That's an impossible criterion. No C library, IMO, can hide the details of
> buffer (aka memory, aka resource) management in C
struct allocator {
void * (*a_malloc)(void *, size_t);
void * (*a_realloc)(void *, void *, size_t);
void (*a_free)(void *, void *);
void *data;
};
struct str *str_new(struct allocator *);
struct str *str_cat(struct allocator *, struct str *, struct str *);
str_del(struct allocator *, struct str **);
... etc, etc. I imagine there'd actually be versions of these same
functions that don't take the initial allocator, and just use a default one.
IMO, C++'s string classes (and many others in the standard C++ library)
handle the allocation problem in a quite general and elegant manner.
Surely a C library could emulate something similar, even if the syntax
were somewhat clunkier?
> and it's not clear to me
> that off-by-ones are substantially more of an issue than NULL or dangling
> pointers.
Both of which can be solved fairly gracefully (to the degree they can be
solved in C) by a library with an interface such as the one I've
outlined. And off-by-ones are a pretty small subset of buffer-size
violations. Forgetting to check, using the size variable for the wrong
buffer, forgetting to initialize the size variable, are all common
mistakes. Most of these can also be solved by a general library; none of
them are solved by using strlcpy() (except "forgetting to check", but as
already mentioned, this isn't a solution, it's an indirection. Instead
of forgetting to check buffer size, it becomes forgetting to use strlcpy()).
> They can only grease the wheels, so to speak. That is, better
> weave the patterns into your code. Encapsulation being one important way to
> accomplish that. But there are many levels of encapsulation, and many/most
> string libraries force you to too high a level of encapsulation for what its
> worth in many instances; rather than encapsulate they obsfuscate.
No argument there.
And I'm not saying that such a library should ever be part of the C
standard (though it might not be terrible, if done as carefully as C++
has done); what I _am_ saying, is that it would go a long way towards
solving the general issue with bounds checking, whereas strlcpy() is
only claimed to do so.
CBFalconer
>
... 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.
CBFalconer
>
... 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.
Micah Cowan
> 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.
Richard Heathfield
> 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
Nick Keighley
> On Feb 27, 4:01 pm, Micah Cowan <mi...@cowan.name> wrote:
> > 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
Randy Howard
(in article <wsOdnXeburUZ-lva...@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.
CBFalconer
> 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.
Richard Bos
> 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
Micah Cowan
> On Thu, 28 Feb 2008 01:53:26 -0600, Richard Heathfield wrote
>>> 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 Cowan
> 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.
William Ahern
<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.
William Ahern
> Micah Cowan <mi...@cowan.name> wrote:
> > CBFalconer wrote:
> > >> Micah Cowan <mi...@cowan.name> wrote:
> <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. ;)
James Antill
> 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.
If you want a real string library, you can do that. There are a couple
of usable ones to choose from[1]. If you want to write a string API, you
can do that too ... and if you are lucky, and have quite a bit of spare
time, you might get something useful out of it.
But don't pretend that strlcpy/strlcat constitute a usable alternative.
See:
http://www.and.org/vstr/security#stringapi
[1] http://www.and.org/vstr/comparison
--
James Antill -- ja...@and.org
C String APIs use too much memory? ustr: length, ref count, size and
read-only/fixed. Ave. 44% overhead over strdup(), for 0-20B strings
http://www.and.org/ustr/
Flash Gordon
> Randy Howard wrote:
>> CBFalconer wrote
>>
> ... snip ...
>>> 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.
>
> My release has documentation mentioning that problem, and what to
> do to comply.
The biggest release is as part of a full implementation where it is, I
believe, documented as being an extension. As they are documented as
being an extension in the main release giving them names starting with
str is appropriate. Personally I would like it if they were in the
standard because the library writers might be able to use a few tricks
to make their versions faster than any implementation I might provide
and sometimes they are the right tool for the job. Similarly I would
like it if strdup was in the standard. However I have my own
implementations (with different names) for where I need them.
--
Flash Gordon
David Thompson
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. <offtopic> 42 is, of course. </>
- formerly david.thompson1 || achar(64) || worldnet.att.net