Path: utzoo!attcan!uunet!lll-winken!ames!oliveb!sun!thetone!swilson
From: swilson%thetone@Sun.COM (Scott Wilson)
Newsgroups: comp.lang.c
Subject: Re: printf, data presentation
Message-ID: <84629@sun.uucp>
Date: 10 Jan 89 19:36:57 GMT
References: <19@xenlink.UUCP> <225800106@uxe.cso.uiuc.edu> <310@twwells.uucp>
Sender: news@sun.uucp
Reply-To: swilson@sun.UUCP (Scott Wilson)
Organization: Sun Microsystems, Mountain View
Lines: 33

In article <310@twwells.uucp> bill@twwells.UUCP (T. William Wells) writes:
>In article <225800106@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>: The important point is that some such function should be a
>: STANDARD C (ANSI C) function, not an operating system dependent
>: kludge. It is obviously too late to get it done right this time
>: around, but next time .... PLEASE!
>
>And to repeat what has been said by many: IT CAN'T BE DONE!
>
>A C compiler can't provide this function if the OS doesn't have the
>facility.

This argument is very similar to one I started some time ago related
to echo/no echo on input, etc.  The point of standard libraries is
to smooth over OS dependencies to provide a uniform interface.  If
inkey() cannot be provided for on some systems, aren't there other
operations mandated by the Standard that are just as hard to provide?
For example, what about the legal modes passed to fopen()?  Aren't
there some systems where you simply can't open a file for simultaneous
reading and writing?  Or open for writing at the end of a file?  What
about fseek(), couldn't that be potentially very inefficient to
implement on some brain-damaged systems?  I don't know the answers to
these questions.  I guess what I'm wondering is:  are there operations
already part of the Standard that are there for historical reasons
(i.e., it has always existed for most implementations) that would be
rejected if it was recommended as a new feature because it was "too
operating system dependent?"


--
Scott Wilson		arpa: swilson@sun.com
Sun Microsystems	uucp: ...!sun!swilson
Mt. View, CA