Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Function prototypes: const parameters
Message-ID: <7316@mimsy.UUCP>
Date: Fri, 3-Jul-87 23:21:24 EDT
Article-I.D.: mimsy.7316
Posted: Fri Jul  3 23:21:24 1987
Date-Received: Sat, 4-Jul-87 15:35:12 EDT
References: <18346@ucbvax.BERKELEY.EDU> <8042@utzoo.UUCP> <2210@hoptoad.uucp> <1261@apple.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 36

In article <1261@apple.UUCP> mikes@apple.UUCP (Mike Shannon) writes:
[Given a prototype like]
>int	open(const char* path, int flags, int mode=0);
>if I do:
>{
>char *pathname = "some.file";
>int i;
>	i = open(pathname, O_RDONLY) .....
>}
>
>	is the above declaration really OK? since the first param isn't CONST?

It is correct.  Declaring the `path' parameter `const char *' tells
the compiler that the `open' routine promises not to modify the
object(s) to which `path' points.  Passing a modifiable (non-const)
array address is legal.  On the other hand, given

	int	mktemp(char *path);

	const char tfname[] = "/tmp/tfXXXXXX";
	... {
		mktemp(tfname);

the compiler can (correctly) complain, since mktemp has been declared
as potentially modifying the pointed-to characters, and these are in
unmodifiable (const) storage.

This means that on systems on which the compiler will indeed complain
about such usages, header files must mark all those functions that do
not modify objects:

	char	*strcpy(char *dst, const char *src);
	int	sprintf(char *buf, const char *fmt, ...);
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris