Re: Bounds checking functions
- From: muntyan@xxxxxxxxx
- Date: Wed, 27 Feb 2008 15:25:09 -0800 (PST)
On Feb 27, 3:02 pm, William Ahern <will...@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:
ymunt...@xxxxxxxxx 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
.
- References:
- Bounds checking functions
- From: Aaron Hsu
- Re: Bounds checking functions
- From: ymuntyan
- Re: Bounds checking functions
- From: William Ahern
- Bounds checking functions
- Prev by Date: Re: incr MACRO
- Next by Date: Re: Bounds checking functions
- Previous by thread: Re: Bounds checking functions
- Next by thread: Re: Bounds checking functions
- Index(es):
Relevant Pages
|
