This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Wish for 2002
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- To: David Wheeler <dwheeler at ida dot org>
- Cc: <libc-alpha at sources dot redhat dot com>
- Date: Thu, 3 Jan 2002 12:27:22 -0800 (PST)
- Subject: Re: Wish for 2002
On Thu, 3 Jan 2002, David Wheeler wrote:
> and I also find them easier to read because less has to be
> done to use them correctly (an experience
> shared by others). Like anything else, if you're not used to
> them you have to learn their meaning, but they're really simple.
Which of these is easier to read:
char db_query[256];
int truncated = 0;
strlcat(db_query, "SELECT * FROM ", sizeof db_query);
strlcat(db_query, table, sizeof db_query);
strlcat(db_query, " WHERE ", sizeof db_query);
strlcat(db_query, condition, sizeof db_query);
if (strlcat(db_query, " ORDER BY ", sizeof db_query) >= sizeof db_query)
truncated = 1;
if (strlcat(db_query, order, sizeof db_query) >= sizeof db_query)
truncated = 1;
/* Did you spot the stupid error in the above?
I caught it just when I was about to send this e-mail! */
if (truncated) { /* ... */ }
or:
char db_query[256];
size_t query_len = snprintf(db_query, sizeof db_query,
"SELECT * FROM %s WHERE %s ORDER BY %s",
table, condition, order);
if (query_len >= sizeof db_query) { /* ... */ }
> They're an incremental aid to a very serious weakness in C.
They are not an aid to C, because they are not part of the C language.
Someone writing a standard C program cannot use these functions without
also writing implementations of those functions as part of that program.
If you use strlcpy without writing it yourself, you are writing in a
HP-UX, BSD or Sun dialect of the C language, not any standard dialect
such as C90 or C99.
If you want to fix a weakness in C, then you have to get these
functions into the next revision of the ISO C standard.
> They force a fixed maximum length, which is sometimes desirable
> and sometimes isn't. But when it's desirable, they help.
How do you know when it's desirable to silently throw away data?
Do you have a magic crystal ball that can enumerate all of the
possible consequences of your coding decision?
The decision to use fixed buffers for strings is often done during
coding, without any traceability to any design document or discussion.
People hack with fixed buffers because C has no dynamic strings, and
it's a lot easier to just deal with fixed buffers.