Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!agate!labrea!decwrl!purdue!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!uxg.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald
From: mcdonald@uxe.cso.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: portability
Message-ID: <225800110@uxe.cso.uiuc.edu>
Date: 18 Jan 89 14:38:00 GMT
References: <1354@tank.uchicago.edu>
Lines: 26
Nf-ID: #R:tank.uchicago.edu:1354:uxe.cso.uiuc.edu:225800110:000:1344
Nf-From: uxe.cso.uiuc.edu!mcdonald    Jan 18 08:38:00 1989


>In article <908@ubu.warwick.UUCP> geoff@emerald.UUCP (Geoff Rimmer) writes:
>>Awww come on!  The main extensions they have provided are not
>>essential to programming in C - a lot of the extensions are things
>>like new keywords like
>>	pascal, fortran, cdecl, far, near, huge.

>Some of us would argue that the ABSENCE of these extensions is more
>useful to the portable-C programmer than their presence!  I have had
>code in the past that used several of these as variable names, etc.
>Unless the compiler manages to allow them as user identifiers outside
>the context of type declarations, they are bound to get in the way.
>(I don't know whether or not MicroSoft's compiler is that clever.)

It is not that clever. BUT THEY CAN TRIVIALLY BE TURNED OFF!!!

Actually, "pascal", "fortran", and "cdecl" are quite useful, and
not only for cros-language purposes. The "pascal" and "fortran"
declarations used on a function make its calling sequence more
efficient. There is a command line switch which makes this the
default "pascal", and then cdecl overrides that for library functions.

The only one that can cause real problems is cdecl, which is in all
the header files. But you can, if you wish to be REALLY standard,
edit it out, and use the command line switch for pure (except they haven't
quite finished the ANSIfication process) ANSI.