Still printf? 2008-5-5(Mon)

The bug

• The following code has two bugs.

  #include <cstdio>
  int main()
  {
    long long int a = 0;
    size_t        b = 12;
    printf("a = %ld, b = %ld\n", a, b);
  }
  

• Under 32bit environment, b is usually zero. This can be found -Wall option with gcc. However, if this printf is indirectly called, like

  void
  my_printf(const char *fmt, ...);
  

  This becomes much hard. The bug here is just typo, but breaking your stack. Since a may be 64 bit, and on 32 bit environment, long int (%ld) is usually 32bit. Then va_arg macro only takes 32bit from the stack. Then, b is taken from the next of stack, but it is still part of a. If you write the code as the following, it seems bug is gone. But the bug is just hidden, deeply.

  #include <cstdio>
  int main()
  {
    long long int a = 0;
    size_t        b = 12;
    printf("a = %ld\n", a);
    printf("b = %ld\n", b);
  }
  

• And the second bug is size_t may not be the long int.

Solution

• You can check all the format string by your own eyes... but,
• My suggestion is use stream. All these problem does not happen automatically. Human makes a mistake more. Ask to check the compiler.

Appendix

• If you can not run away from this by whatever reason (for example, company policy). gcc provides __attribute__ format for your own printf functions,

  // something like...
  extern int
  my_printf(const char *my_format, ...)
  __attribute__ ((format __printf__))
  

  but this is too wizard for me. (This is pointed out by my colleague Peter. Thanks.) Other compilers we could not find the solution, but, ask the gcc to check more problem. I think adding more test for software robustness is no problem for any software developping company. Even though your company's official C++ is cl or icc. If your company policy said that no need to adding robustness test, it seems a good idea to consider to leave a sinking ship.