avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [RFC] Joerg's new vsprint functions.


From: Theodore A. Roth
Subject: Re: [avr-libc-dev] [RFC] Joerg's new vsprint functions.
Date: Wed, 19 Nov 2003 15:47:55 -0800 (PST)


On Wed, 19 Nov 2003, Joerg Wunsch wrote:

> As Theodore A. Roth wrote:
>
> > A similar problem has been noted for printf() and printf_P() in bug
> > #6141.
> >
> > It looks like we need to add quite a few sanity checks. :-(
>
> I'm not sure whether we do want sanity checks at all.  After all, this
> is all pilot errors (people forgetting to check whether their buffers
> or FILE * are NULL), but by adding sanity checks, a penalty will be
> imposed on anyone using these functions, including those who used it
> correctly.
>
> Unfortunately, I didn't find any conclusion in the C standard whether
> the behaviour in these situations might be implementation-defined or
> undefined.  Maybe ask in comp.lang.c?
>

A common usage (according to google) is to do something like this:

  char *buf;
  int length = snprintf (NULL, 0, fmt, ...);
  buf = (char *)malloc (length+1);
  sprintf (buf, fmt, ...);
  ...
  free (buf);

Basically, using snprintf to determine the desired buffer size prior to
allocating the buffer by passing a NULL ptr. This seems like a
legitimate thing to be able to do.

As for penalties, there's three ways to look at it.

  1. The caller has to check for NULL before every call to snprintf().
     So caller's penalty is code bloat for all the checks. Still take a
     speed hit on the checks.

  2. The snprintf() checks for NULL. About the same speed hit, but less
     bloat of overall code.

  3. Neither caller or snprintf() does the check. No code bloat, no
     speed hit, but the results are questionable.

Ted Roth




reply via email to

[Prev in Thread] Current Thread [Next in Thread]