selectively enabling prototypes

When a problem comes along . . . you must whip it daveb at ingres.com
Fri Aug 17 15:32:55 AEST 1990


Please pardon the lengthy inclusion.

In <17424 at haddock.ima.isc.com> karl at kelp.ima.isc.com (Karl Heuer) writes:
>In article <1990Aug13.172452.14217 at ingres.Ingres.COM> I write:
>>In <493 at mtndew.Tustin.CA.US> friedl at mtndew.Tustin.CA.US (Steve Friedl) writes:
>>>[I like to use:]
>>>	#ifdef	USE_PROTO
>>>	#  define	PROTO(name, args)	name args
>>>	#else
>>>	#  define	PROTO(name, args)	name ( )
>>>	#endif
>>>	extern PROTO(char *strcpy, ( char *, const char * ) );
>>>However, I have seen it done "the hard way":
>>>	#ifdef	USE_PROTO
>>>	  extern char *strcpy(char *, const char * );
>>>	#else
>>>	  extern char *strcpy();
>>>	#endif
>>>This looks like a real maintenance nightmare...
>
>Interesting; I would have said that the *former* method looks nightmarish.

This is my conclusion as well; It defeats tags generators and any other
syntax dependant tool.

>>Numberous people believe tha answer is really to write a filter that
>>turns ANSI code into Classic-C code,
>
>That's what I recommend, and what I use for myself%.
>
>>inserting all the casts into function calls as needed.  [But no such program
>>exists.]
>
>Wait a minute; now you've changed the problem.  The original two proposals
>didn't handle the situation of mismatched argument types in a Classic C
>environment, so it's unfair to make that a requirement.  The tool I use isn't
>an ANSI-to-Classic converter, but it is a sufficiently powerful deprotoizer
>for my purposes.

Perhaps; I'm uneasy.  One statement of the problem is "how do I
reasonably write code for both old and new C without going nuts?"  I
think most people would prefer NOT to have to run lint over a program to
verify arg matches when they've gone to the trouble of adding prototypes
-- prototypes solve the problem completely.  But if your method does not
ensure that casts are inserted in function calls, you've made no advance
on ensuring the type-correctness of the old-C.  If you go for the "write
ansi and deprotoize" solution, you may have gone backwards, because you
may not even think to put casts in arg lists.  So, unless the deprotoize
tool does put in the casts, you need to run lint.  Once you're running
lint, you've lost some of the value-added by ANSI.

I'm still inclined to think you need to have casts inserted, and that
nothing short of that is reliable enough to trust.

My apologies to Karl for not having dug into my archives earlier and
finding his converter.  It does indeed do what he advertises, I'm just
not convinced it is enough.  Also see "comp.sources.misc v06i068: Lex
programme to convert pANS to Classic C" by Robert Lupton
(lupton at uhccux.uhcc.Hawaii.Edu), which does the same sort of thing. 
Karl's is ~172 lines, the other ~246.

Someone suggested by mail that the "unprotoize" hack to GCC does the job
I want.  (If it doesn't, it's a lot of baggage to be carrying around
compared to Karl's and Lupton's!)  Does anyone know where I can get a
copy to try?  I have gcc-1.37.1 handy.

thanks,
-dB
--
"In my opinion, most C programs should be indented 6 feet under."
David Brower: {amdahl, cpsc6a, mtxinu, sun}!rtech!daveb daveb at ingres.com



More information about the Comp.lang.c mailing list