[65] in Kerberos-V5-bugs

home help back first fref pref prev next nref lref last post

Re: Const/non-const clashes in alpha2 drop.

daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Tue Nov 27 13:15:43 1990

Date: Tue, 27 Nov 90 12:47:01 EST
From: Bill Sommerfeld <sommerfeld@apollo.com>
To: jtkohl@ATHENA.MIT.EDU
Cc: krb5-testers@ATHENA.MIT.EDU
In-Reply-To: John T Kohl's message of Tuesday, November 27, 1990   11:29:26 am (EST)

   Those are all correct casts.  The input is indeed const, and its
   pointed-to values won't be changed by this code, and the casts are there
   to make our compiler shut up.  Can you make your compiler only complain
   about implicit "illegal conversions" and not explicit ones?

No, I can't, and if I asked for that feature, our compiler group would
look at me as if I was from mars.  Besides, I think it's certainly a
pretty dubious programming practice to convert a pointer to a "const"
object into a pointer to a non-const object; if you can do things like
that, "const" is meaningless in terms of constraining whether or not
certain things can be modified.

I'll see what I can do about actually coming up with some *better*
fixes to these const/non-const conversion clashes.

   getpwnam() has (should have) a prototype (on our systems at least)
   specifying that it takes a const char * as its only argument; perhaps
   your prototypes are in error?  [one of the declarations in our
   fake-stdlib.h didn't have the "const" before; I have fixed that]

Ignore this; it's a bug on our end.

				- Bill





home help back first fref pref prev next nref lref last post