Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!taumet!steve
From: steve@taumet.com (Stephen Clamage)
Newsgroups: comp.lang.c
Subject: Re: Problems with IBM RS6000 C compiler
Message-ID: <386@taumet.com>
Date: 6 Aug 90 15:37:07 GMT
References: <476@mtndew.UUCP> <1893@tkou02.enet.dec.com>
Organization: Taumetric Corporation, San Diego
Lines: 27

diamond@tkou02.enet.dec.com (diamond@tkovoa) writes:

>In article <476@mtndew.UUCP> friedl@mtndew.UUCP (Stephen J. Friedl) writes:
>>	extern int stat(char *filename, struct stat *stptr);
>>Shouldn't the "filename" argument be const qualified?

>But if const is included, it would break a lot of code that presently
>works under Unix(tm) operating system.  (I'm not sure what Posix(tm?)
>standards say.)

No, it wouldn't break any code.  A const-qualified parameter type may
be passed a non-const argument, but the reverse is not true.  If
the parameter is not const-qualified, you cannot pass it a literal
string without a cast.  So the *failure* to const-qualify will break
existing code.  That is, with the above prototype,
	r = stat("myfile", &data);
is illegal under ANSI.
But given
	extern int stat(const char *, struct stat *);
			^^^^^
the following are legal:
	char *fname; /* not const */
	stat(fname, &data);
	stat("myfile", &data);
-- 

Steve Clamage, TauMetric Corp, steve@taumet.com