ANSI C => traditional C conversion tool?

D'Arcy J.M. Cain darcy at druid.uucp
Sat Jun 9 21:00:55 AEST 1990


In article <4004 at milton.acs.washington.edu> mrc at Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes:
>Hi.  I have a rather large software package written entirely in ANSI
>C.  ANSI C's function prototypes type-checking have saved my butt any
>number of times, not to mention the convenient new string functions.
>
>The problem is, I now need to distribute this software, including
>sources, to the general community and I find that most UNIX
>environments do not offer an ANSI C compiler.  One of my co-workers,
>our shell-script/awk/sed expert, gave me a script that does most of
>the conversion, but falters on a couple of rather hairy function
>definitions involving function pointers.  Also, it does not solve the
>problem of the missing string functions.
>
I have never used one of these converters and was wondering if they will
generate a cast for arguments for which a prototype is in scope.  It seems
to me that errors can creep in if you don't do this.  Not only do ANSI
compilers check your parameters to prototyped functions but they also perform
an automatic cast.  Consider:
    int fseek(FILE *stream, long offset, int ptrname);
    ...
    fseek(fp, 0, SEEK_SET);
This will work since the second argument to fseek will be cast to long but
if you convert it to traditional you get:
    int fseek();
and the compiler no longer knows that the argument must be converted to long
and fails silently.

Now before everyone tells me that you can just use 0L, of course you can but
the point is that code that is perfectly legal and correct in ANSI will fail
when converted to traditional unless the arguments have casts added to them.

-- 
D'Arcy J.M. Cain (darcy at druid)     |   Government:
D'Arcy Cain Consulting             |   Organized crime with an attitude
West Hill, Ontario, Canada         |
(416) 281-6094                     |



More information about the Comp.lang.c mailing list