«

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.

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

On Feb 27, 3:02 pm, William Ahern <will...@wilbur.25thandClement.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

On Feb 27, 12:25 pm, Randy Howard <randyhow...@FOOverizonBAR.net>
wrote:
> On Wed, 27 Feb 2008 12:13:53 -0600, jacob navia wrote
> (in article <fq4995$8f...@aioe.org>):
>
>
>
> > Randy Howard wrote:
> >> On Wed, 27 Feb 2008 06:54:23 -0600, jacob navia wrote
> >> (in article <fq3mi2$1j...@aioe.org>):
>
> >>> But wxhy can't we make interfaces better?
>
> >> We can. We do. You can create new interfaces independent of the std
> >> library functions in many cases, or you can create "better" versions of
> >> std library functions via wrappers to add safety features, or to
> >> provide additional functionality. This has been done for ages. Open
> >> source has to a certain degree wiped out the old commercial library
> >> development market, but in either form, alternatives exist by the
> >> bushel.
>
> > Then, if all that is OK, why you and the other people here are
> > ranting when Microsoft proposes a standard about those "wrappers"?
>
> When did I rant about a Microsoft proposal? A simple link will do.
>
> > All functions in the microsoft proposal just add error checking to the
> > basic library functions.
>
> Then why not just introduce them as an open source library that
> provides these wrappers? If they wanted them to be widely adopted and
> quickly, this would be out there. Where can this library be
> downloaded?

Good one!

wrote:
> On Feb 27, 12:25 pm, Randy Howard <randyhow...@FOOverizonBAR.net>
> wrote:
>> On Wed, 27 Feb 2008 12:13:53 -0600, jacob navia wrote
>>> All functions in the microsoft proposal just add error checking to the
>>> basic library functions.

>> Then why not just introduce them as an open source library that
>> provides these wrappers? If they wanted them to be widely adopted and
>> quickly, this would be out there. Where can this library be
>> downloaded?

>
> Good one!

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

The safe string library from microsoft, was open source.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

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

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

Oh good, the problem is solved then. So why are you complaining about
it?



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

William Ahern wrote:
> Knuth and Berstein haven't written many checks.

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

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

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

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

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

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

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

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

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

On Feb 27, 2:46*am, jacob navia <ja...@nospam.com> 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...
> 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.

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

On Feb 27, 4:01*pm, 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...
>
> 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.

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

strlcpy() is not a solution to all the world's problems. A mandate
to use it instead of strcpy() will likely result in some lazy
programmer doing something like:

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

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

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