Some Comments & Questions about ANSI C

[david.f.prosser]

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 other three are
>
>	errno.h	 - this will contain the #defines for error messages.
>		   But will it contain the declaration "extern int errno" ?

Yes, or its equivalent.

>	locale.h - This will contain "properties that depend on local
>		   language, nationality, or culture".  Such as?

Mostly, it contains the declaration of the lconv structure (with 18
or so members), some macros that begin with LC_, and the declarations
of setlocale() and localeconv().

>	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).

It (only) contains the typedefs for ptrdiff_t, size_t, and wchar_t, and
the macros NULL and offsetof().

>
>2. It seems to me that every time I want to #include <stdio.h>, I must
>also #include <stdarg.h> and <stddef.h> beforehand.  This is to stop
>it barfing on the function declarations in <stdio.h> like
>
	[example deleted]
>
>I find this annoying sometimes, especially when working on a simple
>program that is only including <stdio.h> to get _iobuf defined.  Am I
>correct on this?

No.  An ANSI C conforming version of <stdio.h> must not require the
preinclusion of any other headers; nor can it have any other ordering
dependency with respect to any other standard header.  Moreover, after
including <stdio.h>, size_t should be typedef'd and va_list should be
undefined (assuming no other headers have been included).

>
>3. Am I missing something, or is "difftime" the most simple function
>around?  It seems to me that it is essentially a subtract:
>
>	double difftime( time_t t2, time_t t1)
>	{
>		return (double)t2 - t1;
>	}
>In which case, why is it a function?  I'd rather do a subtraction myself!

This presupposes that time_t is a simple numeric representation.  On some
systems, the dates are kept as bit fields within an arithmetic type.

>
>4. I'm still not entirely sure I understand "void *".  If I have a
>function which takes as argument a void *, and I want to pass it the
>variable x (which could be of type char *, int *, or even
>float(*)(int,char*) ), do I have to CAST x to a (void *) when calling
>the function?  Similarly, if the function then returned a void *, and
>I have a variable y of type int *, would I have to do
>	y = (int *) function (......);
>?

First, let's assume that you have a prototype for the function in scope at
the call.  Then, the argument expression is handled as if it were assigned
to an object of type void *: any pointer to an object is automatically
converted to void * for you, unless the type pointed to has more qualifiers
(const and volatile) than the void in the void * target.  Note that your
last example [float (*)(int, char *)] is a pointer to a function and as such,
cannot be (portably) assigned to a void * (with or without an implicit cast).

If there is no prototype in scope for the function at the call, you are
responsible for converting any mismatched types (after application of the
default argument promotions).

The rules when assigning from a void * are symmetric: a void * will be
automatically converted to any other pointer to object type, as long as no
qualifiers (on the pointed to type) are lost in the conversion.

>
>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() is declared in <stdio.h>.  ANSI C knows nothing about <dirent.h>
and opendir(), but both of these are required (as I understand it) by
POSIX 1003.1.

>
>6. Finally, I see there's no strdup in ANSI C.  Sigh.  I guess it's
>back to 
>
>	#define strdup(x) (strcpy(Malloc(strlen(x)+1),(x)))
>
>	:-(

If you desire.  However, such a macro will render your program as
not strictly conforming if <string.h> has been included in the same
compilation.  Try "mystrdup" instead.  Personally, I prefer my own
function that doesn't allow for a NULL return...that's why I don't
really use strdup(), anyway.

>
>Geoff

Dave Prosser	--not an official statement from X3J11--