mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (06/08/90)
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.
The result is a fair amount of manual work that I would like to
automate. Also, it would force me to maintain two sets of sources,
one ANSI one traditional. I would prefer to maintain only ANSI
sources, and have an easy procedure to convert for those sites which
aren't ANSI.
So, my request: Is there some sort of generally-available ANSI
preprocessor that poops out fully traditional C?
Please send mail to mrc@CAC.Washington.EDU, I don't read this
newsgroup.
_____ | ____ ___|___ /__ Mark Crispin, 206 842-2385, R90/6 pilot, DoD#0105
_|_|_ -|- || __|__ / / 6158 Lariat Loop NE "Gaijin! Gaijin!"
|_|_|_| |\-++- |===| / / Bainbridge Island, WA "Gaijin ha doko ka?"
--|-- /| |||| |___| /\ USA 98110-2098 "Niichan ha gaijin."
/|\ | |/\| _______ / \ "Chigau. Gaijin ja nai. Omae ha gaijin darou"
/ | \ | |__| / \ / \"Iie, boku ha nihonjin." "Souka. Yappari gaijin!"
Hee, dakedo UNIX nanka wo tsukatte, umaku ikanaku temo shiranai yo.darcy@druid.uucp (D'Arcy J.M. Cain) (06/09/90)
In article <4004@milton.acs.washington.edu> mrc@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@druid) | Government: D'Arcy Cain Consulting | Organized crime with an attitude West Hill, Ontario, Canada | (416) 281-6094 |
karl@haddock.ima.isc.com (Karl Heuer) (06/11/90)
In article <1990Jun9.110055.10004@druid.uucp> darcy@druid.UUCP (D'Arcy J.M. Cain) writes: >I have never used one of these [ANSI C to Classic C] 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. More correctly, they perform an automatic *conversion* (as if by assignment, not by cast). For example, a mismatch of `int *' vs `char *' must generate a diagnostic if there's no explicit cast. Rather than having the tool add casts to my code, I'd rather have a compiler option to warn about nontrivial conversions of arguments (or use lint). Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint