Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: "Numerical Recipes in C" is nonport
Message-ID: <8507@smoke.ARPA>
Date: 16 Sep 88 14:33:03 GMT
References: <5162@hoptoad.uucp> <225800069@uxe.cso.uiuc.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25

In article <225800069@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>If it were in the
>C language spec they would have to CHANGE THE OPERATING SYSTEM TO
>MAKE IT WORK or else admit "our operating system is so broken that
>we can't have a C compiler". ... I want the C standard to essentially
>force vendors to fix their machines.

X3J11 has rightly observed that such an attitude would most likely
lead to the ANSI C standard failing to gain the widespread support
necessary for a true standard.  There are practical reasons for
promoting a C standard, but imposition of a particular philosophy
of hardware architecture design on the computing industry is not
one of them.

>... when the very same features are ALREADY in C! Among
>these are bit operations ( | & ^ in C) and external names longer than
>6 (six) characters.  

C extern names are not necessarily unique beyond 6 characters,
monocase.  In some environments they are and in some they aren't.
Acknowledging this constraint was one of the most distressing
decisions that X3J11 had to make.  But the fact is, many C
implementors are not in a position to improve the linker that
will of necessity be used with the object code their compiler
generates.