Some Comments & Questions about ANSI C
Karl Heuer
karl at haddock.ima.isc.com
Tue Jun 13 07:34:04 AEST 1989
In article <GEOFF.89Jun11231924 at onyx.cs.warwick.ac.uk> geoff at cs.warwick.ac.uk (Geoff Rimmer) writes:
>1. 15 standard include files are listed in K&R2. Only 12 are
>described in sufficient detail.
The remaining details are in the Standard itself.
> errno.h - this will contain the #defines for error messages.
> But will it contain the declaration "extern int errno" ?
It will declare errno, though perhaps not with that declaration. (In a
multi-threaded environment, something like "#define errno (*__errno())" may be
necessary.)
> locale.h - This will contain "properties that depend on local
> language, nationality, or culture". Such as?
The type "struct lconv", whose members describe such things as the format for
what would be "$15,742.18" in the USA; the function localeconv(), which
returns a pointer to such a (filled-in) struct; the function setlocale(),
which allows the application to specify which locale is to be used; and a
bunch of macros LC_*, which are used to specify to setlocale() which features
are to be changed (character collation, ctype, monetary format, decimal-point
character, strftime() %x/%X format).
> stddef.h - Definition of the type size_t (A7.4.8). But what
> else goes in here? ino_t and dev_t presumably stay
> in sys/types.h (8.6 p 181).
Yes (though <sys/types.h> is part of POSIX, not ANSI C). The other things
defined in <stddef.h> are ptrdiff_t and wchar_t, and the offsetof() macro, and
NULL (which is also defined elsewhere).
>2. It seems to me that every time I want to #include <stdio.h>, I must
>also #include <stdarg.h> and <stddef.h> beforehand.
No. Any implementation that requires this is broken.
>This is to stop it barfing on the function declarations in <stdio.h> like
> size_t fread( void *, size_t, size_t, FILE * );
> /* size_t is defined in <stddef.h> */
The type size_t is defined in both <stdio.h> and <stddef.h> (and elsewhere).
(This requires its definition to be enclosed in an idempotency guard$, alas.)
> int vprintf( const char *, va_list );
> /* va_list is defined in <stdarg.h> */
This one is annoying (to the implementor); it seems that the correct way to do
this is to declare vprintf() using the expansion of va_list rather than the
typedef itself.
>3. Am I missing something, or is "difftime" the most simple function
>around? It seems to me that it is essentially a subtract:
This is true on a POSIX system, where time_t is required to be measure in
seconds since the Epoch. Other ANSI C implementations might encode the time
as YYMMDDHHMMSS in decimal, or something; in this case difftime() would be
nontrivial.
>4. ... do I have to CAST [the arguments and/or the return value of a function
>that expects and/or returns (void *)]?
An implicit conversion will be done; at worst, this will be a warning.
>5. Does the standard say anything about where function definitions for
>fopen and opendir must go? Also, is <dirent.h> mentioned in the
>standard, or is it up to the individual implementor to choose this?
fopen() goes in <stdio.h>. opendir() isn't an ANSI C function; POSIX puts it
in <dirent.h>, which header is likewise not part of ANSI C.
>6. Finally, I see there's no strdup in ANSI C. Sigh.
There's no read() in ANSI C either, but I doubt I'll ever encounter an
implementation that doesn't have it. My solution for strdup() is to keep a
copy in my private library on any implementation that doesn't have one in the
standard place.%
>Geoff
> One of these days, I'm going to write an ANSI C compiler. And
> whenever it encounters some code whose behavior is undefined
> (such as fflush(stdin);) it will draw a picture of Snow White (tm)
> on the screen, and then play Rule Brittania 3 times, before
> crashing with a segmentation fault, and leaving a
> while(1){fork();malloc(UINT_MAX);}
> running in the background.
Quality of Implementation issues are usually resolved by the free market.
Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint
Followups to comp.std.c only.
________
$ A definition is idempotent if executing it twice yields the same result as
executing it once. Since this is not automatically true for typedefs, any
that have more than one home have to be guarded with something like
#if !defined(_T_SIZE)
#define _T_SIZE
typedef unsigned int size_t;
#endif
% Technically this is illegal because the str* namespace is reserved, and
hence a convoluted implementation could use the name "strdup" for something
other than the obvious; but somehow I'm not worried about this.
More information about the Comp.lang.c
mailing list