Some ideas on ETHoberon & LinuxC relationship Andreas F. Borchert

The libc is certainly not a good guide:

* Buffer overruns are not ruled out by design: gets, sscanf etc. * Interface inconsistencies: gets vs fgets, fgets vs fscanf (note the position of the file stream parameter) * Bad interfaces like that of getchar() whose return code can be a character or an error code * Particularly bad buffering system which - ignores the block structure of underlying file systems, and - does not support bidirectional buffering * No provisions exist such that independent libraries can cooperate with each other in - signal handling, - setting up alarms, and - tracking childs.

(Please note that I do not want to bash Ritchie, Kernighan etc. The libc is history and should be taken as such. It is time to abandon C and the libc and it does not help to place other systems (like Java) on top of this historic relic.)

Take a look at why C and libc win in comparison to Lisp and Scheme.

However, if you are looking for an Oberon library that works as an replacement of libc, you might want to take a look at Ulm's Oberon System 1 which is also available for Linux. And it neither depends on C or libc nor does it contain even a single line of C code.

Andreas.

Linux Gentoo users might want to use ftp:--ftp.mathematik.uni-ulm.de-pub-soft-oberon-ulm-i386-ulm-oberon-i386-0.8.6.ebuild.tar.bz2 The packages consist of Oberon sources and binaries which allow to bootstrap the system. The linux port is still beta and not yet finished. The core libraries are, however, quite stable since more than ten years.