Path: utzoo!attcan!uunet!lll-winken!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: portability
Message-ID: <9419@smoke.BRL.MIL>
Date: 18 Jan 89 18:48:24 GMT
References: <16573@iuvax.cs.indiana.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25

In article <16573@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes:
>->	pascal, fortran, cdecl, far, near, huge.
>This linking and memory-model-monkeying is inherently non-portable
>anyway; the operations just don't make any sense on most systems.

Obviously if a program USES these in the MicroSoft sense, it is
non-portable.  However, if it uses them for its own purposes, then
it may very well break when ported to a MicroSoft implementation.
One hopes that MicroSoft will provide alternative names within the
name space reserved for implementations (e.g. "__pascal") for these
extensions, in which case those names would not need to be disabled
for standard conformance.  But the non-underscore names DO need to
be disabled to conform to the standard (unless, as I mentioned
before, the compiler is smart enough to allow all strictly
conforming programs to use the names for their own purposes, with
MicroSoft's special meaning active only in cases that could not
occur in a strictly conforming program).

>Hey!  What'd you do with the 'entry' keyword?!?!?  A 'goto' is only half
>a 'goto' if I can't have multiple entries to a procedure!  Cheee....

"entry" never was supported by the AT&T UNIX C compilers.  I guess by
the time Dennis and Steve got around to worrying about it, they had
realized that it was not an idea that should be encouraged.  X3J11
quit reserving it as a keyword because there was no point in doing so.