This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]