🚀 go-pugleaf

In article <1991Apr25.201855.27893@watdragon.waterloo.edu> ccplumb@rose.waterloo.edu (Colin Plumb) writes:
>steve@taumet.com (Stephen Clamage) wrote:
>>ccplumb@rose.waterloo.edu (Colin Plumb) writes:
>>>- A large fraction of the ANSI C library can't be written in *strictly
>>> conforming* ANSI C.
>> In the full posting you mentioned only setjmp and longjmp...
>> Can you name any other functions in the standard C library ...
>First, I'll ignore the linker tricks used so library functions can call
>other library functyions even without the proper incliude files
>(e.g. assert() calls abort()).  I'll also assume that you don't want
>a trivial library where everything hard returns failure (e.g. clock()).

As a contributor to the (apparently now defunct) "DLIBS" project, and an
implementor of public-domain standard library functions, I've studied
this issue extensively and feel that some comments based on practical
experience would be useful.

There are no "linker tricks" required.  A strictly conforming program
need not include standard headers to access standard functions; it can
explicitly declare the ones it uses.

Most of the standard library functions are required to perform their
functions; certainly the majority should be implementable on all systems.

>float.h - not possible
>limits.h - not possible
>stddef.h - not possible (except for NULL)

All these CAN be written in a strictly conforming manner.
However, it may well be the case that no SINGLE definition of each
type or macro is UNIVERSAL.  Portability and strict conformance are
quite different properties.

I have, however, seen implementations of <limits.h> wherein the vast
majority of the definitions are also portable ones.

>stdio.h - large parts are writeable in C, although a number of #defines
>	and typedefs can't be portably declared, and remove(), rename(),
>	tmpnam(), fclose(), fopen(), some low-level read/write primitives
>	(fread/fwrite, fgetc/fputc, or whatever), and some seek-type
>	primitives are OS-dependent.

All of <stdio.h> can be implemented as strictly conformant AND portable;
however, one of course must assume the existence of a common set of low-
level IO functions such as __read() and use them in a minimally demanding
manner.

>Does that give some idea of the size of the problem?  If you pick some
>primitives to write it in terms of, you can write almost everything
>in Strictly Conforming C, and a great deal more in semi-portable
>C, but there are a lot of gtchas hiding in there.

Those points are correct, but note the shift from "strictly conforming"
to "completely portable".

P.J. Plauger's new book ("The Standard C Library", published by
Prentice-Hall "any day now") should provide concrete grounds for
further discussion of this issue.