Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: Elevators
Message-ID: <11445@smoke.BRL.MIL>
Date: 31 Oct 89 03:03:37 GMT
References: <1159.25475CBB@urchin.fidonet.org> <11038@riks.csl.sony.co.jp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21

In article <11038@riks.csl.sony.co.jp> diamond@ws.sony.junet (Norman Diamond) writes:
>In article <1159.25475CBB@urchin.fidonet.org> Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) writes:
>>For example, an elevator controller ...
>But it also can't be programmed in C!!!!  ANSI says that the execution
>character set must include a carriage return, audible alarm (well --
>I guess an elevator has that), vertical tab (does an elevator have
>that?), horizontal tab, and a bunch of ASCII-like characters.  And
>you gotta have fseek().  Anyone want to design a C standard for a
>stand-alone environment, which ANSI forgot to do?

Don't be absurd.  Any modern character set (e.g. USASCII) meets the
requirements of the Standard.  The character display semantics of
Section 2.2.2 are not only merely a statement of intent, not a firm
requirement, but also apply only to writing characters to a display
device, which is done in Standard C only by invoking an appropriate
library function.  However, in the freestanding environment, the
usual standard library functions are not required to be available.
Thus there is no reason at all to think that the C characters that
in a hosted environment have certain intended functions when written
to a display device need have any function at all (other than as
integer code values) in an embedded (freestanding) environment.