unproto Synopsis /somewhere/cpp ... cc cflags -E file.c | unproto >file.i; cc cflags -c file.i DescriptionThis document describes a filter that sits in between the UNIX C preprocessor and the next UNIX C compiler stage, on the fly rewriting ANSI-style syntax to old-style syntax. Typically, the program is invoked by the native UNIX C compiler as an alternate preprocessor. The unprototyper in turn invokes the native C preprocessor and massages its output. Similar tricks can be used with the lint(1) command.
Language constructs that are always rewritten:
Multiple string tokens are concatenated; an arbitrary number of whitespace or comment tokens may appear between successive string tokens.
Within string constants, octal escape sequences are rewritten to the three-digit \ddd form, so that string concatenation produces correct results.
Language constructs that are rewritten only if the program has been configured to do so:
Note: (void) argument lists are always replaced by empty ones.
ANSI C constructs that are not rewritten because the traditional UNIX C preprocessor provides suitable workarounds:
#define string(bar) "bar" /* instead of: # x */ #define paste(x,y) x/**/y /* instead of: x##y */
There is a good reason why the # and ## operators are not implemented in the unprototyper. After program text has gone through a non-ANSI C preprocessor, all information about the grouping of the operands of # and ## is lost. Thus, if the unprototyper were to perform these operations, it would produce correct results only in the most trivial cases. Operands with embedded blanks, operands that expand to null tokens, and nested use of # and/or ## would cause all kinds of obscure problems.
Unsupported ANSI features:
/wherever/stdarg.h, provided with the unproto filter. DiagnosticsProblems are reported on the standard error stream. A non-zero exit status means that there was a problem.
Declarations of (object) are misunderstood and will result in syntax errors: the objects between parentheses disappear.
Sometimes does not preserve whitespace after parentheses and commas. This is a purely aesthetical matter, and the compiler should not care. Whitespace within string constants is, of course, left intact.
Does not generate explicit type casts for function-argument expressions. The lack of explicit conversions between integral and/or pointer argument types should not be a problem in environments where sizeof(int) == sizeof(long) == sizeof(pointer) . A more serious problem is the lack of automatic type conversions between integral and floating-point argument types. Let lint(1) be your friend.
Wietse Venema (firstname.lastname@example.org) Eindhoven University of Technology Department of Mathematics and Computer Science Den Dolech 2, P.O. Box 513, 5600 MB Eindhoven, The Netherlands Last Modification 92/02/15 17:17:09 Version/Release 1.5