3

[Updated organization and content for clarity]

The Real Question

What would be a good way, for C, to help a programmer, while s/he's typing, write safe and correct calls to project-specific printf-like debugging functions?

C macros? C wrapper functions? Code editor macros or templates? Other?

Background Questions and Answers

Much software uses printf or printf-like functions for debugging, either ad-hoc when there's a problem, or for debug logs. And yet it's error-prone.

Q1: How do we know?
A1: Static analyzers have categories for printf-mismatch errors -- it's a common class of errors -- and I often see those tools call out those warnings on C code.

Q2: What are the sub-classes of this error?
A2: Mainly, wrong format specifier, and wrong number of format specifiers. Often the real error is the converse: wrong variable type, or wrong number of variables for print-out.

Q3: Why do we care?
A3: At best, causes wrong logging information and impedes debugging. At worst, crashes the software.

Q4: Has anyone tried to do anything about this problem?
A4: Sure, though I haven't seen any for C (as opposed to C++ or other), for example:

http://www.ddj.com/cpp/184401999?pgno=1 http://mi.eng.cam.ac.uk/~er258/cvd/tag/html/group__printf.html

What's missing for me in these offerings and others, besides the fact that right now I'm looking at a product written in C and need to solve the problem for C, is that they are after-the-fact solutions. They can avoid crashes, and can provide warning explanations of what went wrong, and that something went wrong, but they certainly can't guess what the programmer's intention was (see esp. Q&A #2 above).

Q5: Why is using printf so error-prone?
A5: Because writing a printf call requires the programmer to mix types and numbers of variables, format specifiers, free text string constants, and punctuation -- all of which look very similar to each other -- on one line together.

talkaboutquality
  • 1,312
  • 2
  • 16
  • 34
  • 1
    Switch to C++. iostream output may be a bit slow at times, but it is type safe. –  Dec 28 '09 at 14:57
  • 1
    It's type safe, but often not usefully so. Consider what happens when you do something like `cout << this`. It won't give you a compile error, but when you do finally run the program, you'll (most likely) end up with the numerical value of this `this' pointer. There is a certain advantage to printf style "repetititon" of the "type". This is part of what can make libraries like boost.format appealing, but that still has some of the issues as printf (e.g. you find out about too many arguments at runtime, albeit in a much nicer way than messed up varargs). – Logan Capaldo Dec 28 '09 at 15:11
  • 1
    @Neil I know. But iostreams make it very easy to get away with getting that distinction wrong without telling you until it is too late. I'd much rather see something like `cout << ptr(aptr)` to get the current `cout << aptr` behavior, and have `cout << aptr` simply not compile. This is the kind of mistake the type system could prevent, but iostreams implementation does not. Likewise the behavior with manipulators like hex, or boolalpha. E.g. `cout << hex << "a string" << endl` compiles, is typesafe and runs, but is the output what you were intending? – Logan Capaldo Dec 28 '09 at 15:24
  • 3
    It's not up to the compiler to guess my intent. –  Dec 28 '09 at 15:30
  • 1
    I'm not talking about "guessing". I'm talking about making it harder to write incorrect code. If hex were a member function (or a constructor) that took its numeric argument instead of a manipulator you could never say `cout.hex() << "a string"` or `cout.hex("a string")` or `cout << hex("a string")`. There is no guessing going on. The only thing iosteam buys you over printf in this regard is that it will never crash (well, almost never. `char *s = 0; cout << s` because now it's treating s like a c string instead of a pointer). – Logan Capaldo Dec 28 '09 at 15:43
  • In any case, while "change programming languages" is a helpful response in general, it does not address my question today, where we are stuck in C, and thus requires an answer for C. – talkaboutquality Dec 30 '09 at 09:04

5 Answers5

8

gcc provides -Wformat to warn about printf/scanf/strftime/strfmon format errors.

$ gcc -Wformat -c -o test.o test.c
test.c: In function ‘main’:
test.c:5: warning: format ‘%s’ expects type ‘char *’,
          but argument 2 has type ‘int’
$ cat test.c
#include <stdio.h>

int main(int argc, const char *argv[])
{
     printf("%s\n", 0);
     return 0;
}
richq
  • 55,548
  • 20
  • 150
  • 144
  • 1
    Note also that `-Wformat` is included in `-Wall`. I generally try to compile all of my code with `-Wall -Werror`, and then exclude any warnings that are actually spurious; it leads to much cleaner code and makes you actually notice when you get new warnings in a big project. – Brian Campbell Dec 28 '09 at 17:08
  • I clarified my question. Emphasis on "while typing" and clarification that these are "printf-like" functions. Yes, we know about printf compiler warning flags. For printf-like functions, we need to use preprocessor attributes to tell gcc that our functions are like printf. Similarly for lint. We're using these solutions but they are after-the-fact. – talkaboutquality Dec 30 '09 at 09:18
  • @talkaboutquality: I assume you mean function attributes, which don't have anything to do with the preprocessor (http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Function-Attributes.html#Function-Attributes) – Hasturkun Dec 30 '09 at 10:23
  • 1
    In that case: use Java and an IDE like Eclipse or Netbeans. It's really the only way if you want as-you-type error flagging. The C preprocessor and C++'s "impossible" grammar means this is DOA for C IDEs. – richq Dec 30 '09 at 13:54
4

In GCC, there's a built in way to prevent use of functions:

#pragma GCC poison printf

It's better than "-Wall" because it's an error, not an warning. I've no idea how printf would be replaced - maybe by lots of specialized functions.

See GCC pragmas

nobody
  • 19,814
  • 17
  • 56
  • 77
diciu
  • 29,133
  • 4
  • 51
  • 68
3

Use a compiler which can check types and format of a printf(). Most modern compilers should be able to do it. For GCC, -Wall is your friend (or -Wformat if you want just the format checks). See the warning options for details.

Other than that, your only option is to add a #define printf ILLEGAL_DO_NOT_USE to a common header file of your projects and supply a different function that does the same job in a safe way. Good luck with that approach ;)

[EDIT] Your issue is that C can't attach type information to something passed as a parameter by itself. So what you could do is something along these lines:

safe_printf_like_function("%d %s %c\n", INT_TYPE(value), STRING_TYPE(s), CHAR_TYPE(c));

The macros must contain casts to the type (so the compiler can notice that the type is wrong as you pass it in) plus it must expand to something that carries the type information.

Drawback: Any C programmer is going to scream out in anguish if you present them such an API. C just isn't meant to be this way. C is unsafe. Period. It's meant to be unsafe. By design, habit and tradition. If you want a safety net, C is not for you.

That said, you can achieve a certain level of safety in C but at a cost: You must forbid the use of varargs anywhere in the code. Pointers and arrays must be wrapped in code that checks sizes, etc. So yeah, it's possible but it's not C anymore.

Face it, C is from 1972. It's ancient and it shows. For almost 35 years, no one managed to find a clever way to make C safe (see C++ for an attempt and the amount of success you can expect).

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • I clarified my question. Emphasis on "while typing" and clarification that these are "printf-like" functions. We know about printf compiler warning flags. For printf-like functions, we use preprocessor attributes to tell gcc our functions are like printf. Same for lint. We're using these solutions but they are after-the-fact. Good idea on how to forbid a given function, in a compiler-independent way. But, given my clarification, our problem is not forbidding use of printf and replacing it with wrapper functions. We already have wrapper functions. It's making using them less error-prone. – talkaboutquality Dec 30 '09 at 09:20
  • I've edited my answer. In short: What you have is the best you can get. – Aaron Digulla Dec 30 '09 at 09:47
  • LOL I guess I was hoping against hope. Maybe the best we can do is using computer speed (Moore's law) to make after-the-fact tests (compiler, lint) run all the time in the background to continuously highlight typing and coding errors. Thanks for your thorough answer. – talkaboutquality Dec 30 '09 at 19:20
  • Well, there are new languages which are much better at this. Just have a look at Groovy or Python. Granted, they are slow today but JIT compilers get better every day which means all programs written in these languages get faster with every improvement of the VM (which isn't true for C). – Aaron Digulla Dec 30 '09 at 21:44
1

The best luck I had was to use tools like lint or splint and pitch an absolute fit when stuff was not passing 100%. Combined with some sort of code inspection (to handle cases where the warnings are being rightfully suppressed), this was enough to get the job done, though it was definitely not an ideal solution.

Hank Gay
  • 70,339
  • 36
  • 160
  • 222
  • Nice but that's my starting point. That's after-the-fact (after programmer has typed the erroneous printf call). I'm looking for prevention -- preventing erroneous printf calls from being typed. – talkaboutquality Dec 28 '09 at 15:16
  • 2
    From being typed or from being compiled? if the former, that's impossible. If the latter, one could integrate lint like tools into the build system such that if they failed it would be treated as a build break. – Logan Capaldo Dec 28 '09 at 15:45
  • @Logan if you have a CI system, that is 100% the way to go. – Hank Gay Dec 28 '09 at 15:52
  • From being typed. Nothing is impossible. Just have to think harder. That's why I'm asking on stackoverflow. – talkaboutquality Dec 30 '09 at 09:21
  • If nothing is impossible, than typing an incorrect printf is not impossible no matter how good the check ;). – Logan Capaldo Jan 02 '10 at 07:10
0

It's not an easy problem to solve. If you are going to be writing specific patterns (like, say, "%s: %d", you can use a macro or (preferably) a wrapper function. It will not be possible to duplicate the functionality of printf() without duplicating the complexity.

Code editors will find it difficult to check, since determining value types (which is necessary to avoid mismatches) requires parsing the C program. It's possible for the C compiler itself to warn, but not many do (I'd like it if they did).

C++ avoids the problem with iostreams, which take advantage of operator overloading, but that's not an option in C.

One rule I can give is not to print out a string variable like printf(string);. Always use printf(%s, string); instead, since that avoids hard-to-find bugs if there's a percent sign in the string.

David Thornley
  • 56,304
  • 9
  • 91
  • 158
  • I wouldn't mind "duplicating the complexity" if I could export that complexity out of printf and its use to the wrapper, and then get that wrapper right once and for all. Regarding the rule, good point, but I don't think it catches a very broad sub-class of errors. True that one shouldn't omit the format specifier altogether, but when putting it in, it's so often right in the middle of constant text, as in printf("The software had a %s problem on line %d",sProblemType,iProblemLineNumber). – talkaboutquality Dec 28 '09 at 15:15
  • Regarding code editors' checking, if I combine that with @Hank Gay's answer, one could put lint in the background running all the time. That's closer to prevention but still not quite. Looking for an outside-the-box answer to the question. – talkaboutquality Dec 28 '09 at 15:18