Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!princeton!njin!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: ANSI C standard library Message-ID: <15985@smoke.brl.mil> Date: 26 Apr 91 18:58:28 GMT References: <1991Apr20.092845.14164@watdragon.waterloo.edu> <681@taumet.com> <1991Apr25.201855.27893@watdragon.waterloo.edu> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 58 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 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 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.