Problems with IBM RS6000 C compiler

[Karl Heuer]

In article <1893 at tkou02.enet.dec.com> diamond at tkou02.enet.dec.com (diamond at tkovoa) writes:
>In article <476 at mtndew.UUCP> friedl at 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 at kelp.ima.isc.com or ima!kelp!karl), The Walking Lint