Actually this is already the case. Try printing a message to stderr in an MS
Windows GUI program, for example. There might be a way to catch the output,
but I haven't found it.
That's a Windoze problem (in other words, it isn't meeting the standard
in that respect). It could easily pop up a message box, for instance,
or a text window. Complain to M$...
Most games consoles also have a very limited subset of the standard library,
and often that is useless, for instance because double precision arithmetic
is emulated in software.
They are catered for as freestanding implementations, which only need to
support the functions in <float.h>, <limits.h>, <stdarg.h> and
<stddef.h> (in C90; C99 adds a few more). There is, of course, no
guarantee that any aspect of the implementation is suitable for any
specific purpose (speed, size of object code, etc.) only that it works
according to the standard and produces the correct result.
My own view is that many programs need to be able to address a text raster
on a console, and many more need to be able to access a graphical window and
mouse. It would only take half a dozen functions to support these things
And many more don't. Almost all of the programs I've written in the
last 25 years (about 20 of them using C or C++ full-time) are quite
happy with a text stream as user input and output.
Win * TextWindow(int width, int height, int *wgot, int *hgot)
void printat(Win *win, int x, int y, char ch)
Win *GraphicsWindow(int width, int height, int *wgot, int *hgot, COLORMAP
*col)
void setpixel(Win *win, int x, int y, long rgb)
/* this one for efficiency */
void drawimage(Win *win, int x, int y, int width, int height, long *image)
/* if delay is non-zero, this could double as the synch function to flush
output to
the screen */
int querymouse(Win *win, int *x, int *y, int delay)
int kbhit(void)
void closeWindow(Win *win)
Well, you've now extended it to graphics terminals, thus limiting it
even more to certain hardware and operating systems.
This would release third parties to produce systems for buttons and drivers
and so on. Text could default to 16 pixels by 20, or whatever is convenient.
What is 'convenient' is a text mode terminal which can display at least
80 characters width in sequential order, and an input device which
generates characters. That is all that is needed for a conforming
hosted C implementation. Your suggestion would make it necessary to
provide even more hardware and functions to interrogate it (there is no
point in having a portable window without means to find out how big it
can be, how many colours it supports, how big the text is, etc.).
Anyone really worried out appearance in graphics mode would build a font
library on top of the access functions anyway.
No, they would (and do) go directly to the system API (or to the
hardware) to do it efficiently (try telling a games programmer that he
has to use functions which set one pixel at a line to draw a line, when
the hardware implements it as a single operation!). And no one would
ever agree about which functions are basic and which can be built
sensibly on top, because all of the hardware is different. Look at how
many graphics libraries there are, all with different interfaces because
they are designed for different things.
The point of the C library is that it is supposed to support the minimum
necessary to write workable programs, and allow extra libraries and
headers to do anything else.
Note that the curses library can be implemented using only the standard
C functions -- of course, it has to know which escape sequences to
issue to do things like cursor addressing, switching echo off, etc., but
for many terminals those can be done without any direct OS access at
all. The same could be true for a graphics system (the Tektronics
terminals, which are still emulated in some xterms, used an serial
character stream for graphics) and for pointing devices. But it's up to
the implementer and the user to determine the hardware characteristics
for those, not for the C standard to specify minimum hardware levels.
(I'm not too happy with some of the C99 specifications, they seem to be
going in the direction of too much hardware knowledge. It started with
specification of a particular floating point format, and supporting
complex arithmetic and the horrible type-generic macros...)
Chris C