Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Problems with IBM RS6000 C compiler
Message-ID: <17240@haddock.ima.isc.com>
Date: 6 Aug 90 17:01:04 GMT
References: <476@mtndew.UUCP> <1893@tkou02.enet.dec.com>
Reply-To: karl@kelp.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 28

In article <1893@tkou02.enet.dec.com> 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?
>
>Suppose someone has a call of [one of] the form[s]
>  x = stat("myfile", &my_stat);
>  x = stat(my_mallocked_buffer_p, &my_stat);
>But if const is included, it would break a lot of code that presently works
>under Unix(tm) operating system.  'Fraid I have to disagree with Karl Heuer's
>answer!

Sorry, 3.2.2.3 agrees with me.  It doesn't break existing code, because it's
perfectly legal to assign from `char *' to `char const *'.  (Only *removing*
the qualifier requires an explicit cast, and even then you'd better know what
you're doing.)

>stat is not defined by ANSI, so either way, it would not violate ANSI.  (I'm
>not sure what Posix(tm?) standards say.)

True; though the same question could be phrased entirely within the ANSI world
by using, say, strlen() as the example.  The 1988 edition of POSIX doesn't use
prototypes to describe its function interfaces; I hear this has been fixed in
the 1990 edition.  Anyway, if vendors are going to provide a prototype for a
function, they should const-qualify any pointer arguments that it uses for
read-only access.

Karl W. Z. Heuer (karl@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint