Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!lobster!nuchat!sugar!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.lang.c Subject: Re: ANSI C -> non-ANSI C Message-ID: <=+_7-63@xds13.ferranti.com> Date: 4 Dec 90 21:34:04 GMT References: <90335.163132TRM900@psuvm.psu.edu> <14630@smoke.brl.mil> <2880@lupine.NCD.COM> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 21 In article <2880@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: > This is indeed a problem which currently unprotoize doesn't not solve. > However I do not think that unprotoize *should* solve it. I don't know what the name of the tool to solve it should be, but I think that such a tool would really help spread ANSI C. As it is, ANSI C programs are just plain incompatible with pre-ANSI compilers, and simply stripping off the prototypes does not solve that problem. I appreciate the work you've done, though I won't be likely to benefit from it... GCC doesn't like little machines like the ones I use. > By the way... the above example is not really a very good one because it > seems to assume that NULL is defined to plain `0' and (more importantly) > because it assumes that ((int) 0) and ((char *) 0) have different > representations (which they do not on any of the machines that I work on). Both of these are reasonable assumptions outside the world of VAX-class machines. In addition, this particular problem is my #1 headache converting such code to run on small computers. Floating point problems are relatively uncommon, since code that's broken in the first place isn't as likely to show up in a source distribution as non-portable code. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com Brought to you by Super Global Mega Corp .com