poser@csli.Stanford.EDU (Bill Poser) (11/16/90)
Would anyone care to comment on the availability of ANSI-conformant compilers, or at least, compilers that handle ANSI extensions like prototypes? If I start ANSI-fying existing classic C code, how likely am I to run into a platform on which I can't compile it? Just about everything I currently deal with has gcc, which takes care of the problem, but you never know. Are compiler producers ANSI-fying their compilers rapidly? Bill
gwyn@smoke.brl.mil (Doug Gwyn) (11/16/90)
In article <16440@csli.Stanford.EDU> poser@csli.Stanford.EDU (Bill Poser) writes: >Are compiler producers ANSI-fying their compilers rapidly? Not all that rapidly; I expect to encounter environments without standard conforming C implementations for the next few years yet. The problem is worst for obsolete CPU product lines, for which there is little economic incentive for the vendors to modernize the support software. I think three of our five major mini vendors probably fall into that category. Consequently, I key on the __STDC__ preprocessing macro and include code for both standard-C and UNIX-pcc environments. This works fairly well and could be done more spiffily than I usually bother to do it.
poser@csli.Stanford.EDU (Bill Poser) (11/17/90)
In article <14487@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >Consequently, I key >on the __STDC__ preprocessing macro and include code for both >standard-C and UNIX-pcc environments. This works fairly well >and could be done more spiffily than I usually bother to do it. Doesn't this mean that you either don't use prototypes or have to include both a prototype and a non-prototyped declaration for every function?
gwyn@smoke.brl.mil (Doug Gwyn) (11/17/90)
In article <16457@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes: >Doesn't this mean that you either don't use prototypes or have to >include both a prototype and a non-prototyped declaration for every >function? There is no requirement to use prototypes even in an ANSI C environment. However, in fact we do use them, in order to obtain the benefit of compile-time parameter type checking ("lint" can also do this) and especially possible violations of "const" parameter qualification. While we don't do anything particularly slick in declaring functions both ways, there are methods for automating this, e.g. /* in your system configuration header: */ #ifdef __STDC__ #define ARGS(args) args #else #define ARGS(args) () #endif /* in your module/package headers: */ #include "std.h" /* the above system configuration header */ extern bool FunkyFunc ARGS((int number, char *name)); /* etc. */ You could also do something similar for function definitions.
kaiser@ananke.stgt.sub.org (Andreas Kaiser) (11/18/90)
In your msg to All, dated <17 Nov 90 18:41>, it said:
BP> Just about everything I currently deal with has gcc, which takes
BP> care of the problem, but you never know. Are compiler producers
BP> ANSI-fying their compilers rapidly?
At least IBM cares. The AIX RS/6000 compiler pretends to conform to the ANSI standard.
Andreas
--
:::::::::::::::::::: uucp: kaiser@ananke.stgt.sub.org
:: Andreas Kaiser :: fido: 2:509/5.2512 & 2:507/18.7206
::::::::::::::::::::epames@eos.ericsson.se (Michael Salmon) (11/19/90)
In article <16457@csli.Stanford.EDU> poser@csli.stanford.edu (Bill Poser) writes: >In article <14487@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >>Consequently, I key >>on the __STDC__ preprocessing macro and include code for both >>standard-C and UNIX-pcc environments. This works fairly well >>and could be done more spiffily than I usually bother to do it. > >Doesn't this mean that you either don't use prototypes or have to >include both a prototype and a non-prototyped declaration for every >function? I recently saw a programme that used cpp macros to define either prototypes or use traditional declarations. The idea is to use a macro for each number of parameters then expand it 2 ways. Unfortunately it does mean that programmes that expect a certain format (perhaps indent) may become confused. Michael Salmon L.M.Ericsson Stockholm