Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!sdrc!thor!scjones
From: scjones@thor.UUCP (Larry Jones)
Newsgroups: comp.lang.c
Subject: Re: Problems with IBM RS6000 C compiler
Message-ID: <129@thor.UUCP>
Date: 6 Aug 90 14:27:07 GMT
References: <476@mtndew.UUCP> <1893@tkou02.enet.dec.com>
Organization: SDRC, Cincinnati
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 the form
<   x = stat("myfile", &my_stat);
< or
<   x = stat(my_mallocked_buffer_p, &my_stat);
< 
< stat is not defined by ANSI, so either way, it would not violate ANSI.
< 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.)  'Fraid I have to disagree with Karl Heuer's answer!

How would it break code?  It is perfectly valid to assign a pointer
to non-const to a pointer to const as shown in your examples.  It's
only the other direction (assigning a pointer to const to a pointer
to non-const) that requires a cast.

I agree with Steve -- filename should be const just like it is in
all of the stdio functions (according to ANSI).
----
Larry Jones                         UUCP: uunet!sdrc!thor!scjones
SDRC                                      scjones@thor.UUCP
2000 Eastman Dr.                    BIX:  ltl
Milford, OH  45150-2789             AT&T: (513) 576-2070
The living dead don't NEED to solve word problems. -- Calvin