Xref: utzoo comp.lang.c:37171 comp.std.c:4473
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: Portability / C Language Implementation
Message-ID: <15488@smoke.brl.mil>
Date: 16 Mar 91 22:24:30 GMT
References: <12375@pt.cs.cmu.edu>
Followup-To: comp.lang.c
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 22

In article <12375@pt.cs.cmu.edu> hjelm@g.gp.cs.cmu.edu (Mark Hjelm) writes:
>I should clarify:  I am well aware of what the Ansi standard says
>about portable programs.  As an implementor of tools supporting
>heterogeneous distributed computing, I am interested in specific
>machines that have (or could have) "interesting" C implementations.  I
>would like to produce a list of such machines so that I can plan ahead
>in my implementation-level code and recognize the machines when I hear
>their name.

Essentially ALL present-day computer systems are capable of supporting
conforming implementations of C.  Rather than trying to catalog lists
of specific system names, which would become quickly obsolete anyway,
you're much better off having the code automatically adjust to the
particular environment by reacting to properties of the environment.
For example, the MUVES "Dx" package supports data interchange between
heterogeneous architectures, but it automatically configures itself
(a) at compile time, using preprocessor arithmetic tests, and (b) at
run time, by exchanging test data between the systems when a connection
is established.  Method (a) can in theory be problematic, but in
practice is a fairly reliable method of determining certain properties
of the host architecture.  Method (b) is foolproof if you code it
carefully.