Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Handling of NULL strings by TI C library

C library shipping with TI ARM compiler 5.2.8 handles NULL string pointers passed to the printf family if functions incorrectly.

The bug is in arm_5.2.8/lib/src/_printfi.c, in _pproc_str, line 482:

    /*------------------------------------------------------------------------*/
    /* Handle NULL strings.                                                   */
    /*------------------------------------------------------------------------*/
    if (strbuf == NULL)
    {
       _outc('\0', _op);
       return;
    }

The way it "handles" NULL strings is by inserting a NUL character, which is wrong. Other C libraries either emit nothing or a predefined string, usually "(null)" or some such.

here's a test code snippet:

  char buf[100];
  const char *s = NULL;
  int n = sprintf(buf, "Hello '%s' '%.*s'!", s, 0, s);
  printf("\n%d >%s<\n", n, buf);

on a GNU C library it produces

18 >Hello '(null)' ''!<

On TI library it produces

12 >Hello '<

Also note the behavior when %.* format is used - GNU libc handles it correctly and does not output anything in this case

  • Passing a null string to sprintf (and other similar functions) is undefined behavior.  The function is not required to detect it, or do anything special.  It turns out many implementations do detect it, but do not respond in a standardized way.

    That being the case, I filed CODEGEN-1717 in the SDOWP system not to report a bug, but to request an enhancement.  It requests that the printf functions be changed to handle NULL string pointers in the same manner as GCC.  At this time, I do not know if this request will be accepted.  

    Normally, you could follow CODEGEN-1717 with the SDOWP link below in my signature.  However, at this time, there are problems which prevent seeing enhancement requests.

    Thanks and regards,

    -George