[1347] in Kerberos-V5-bugs
krb5b4pl3: problems with "const" configuration and usage
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Mon Apr 24 12:20:13 1995
From: "Jonathan I. Kamens" <jik@cam.ov.com>
Date: Mon, 24 Apr 1995 12:23:39 -0400
To: krb5-bugs@MIT.EDU
In krb5b4pl3, the configure strict in include/krb5 determines whether
"const" is supported by the compiler being used, and if not, defines
const to nothing so that it doesn't get used by any of the krb5
sources when they are compiled.
That's all well and good when the krb5 header files are being used by
only one compiler and only when compiling the krb5 sources. But what
happens when someone wants to link their own programs against the krb5
libraries, and they use a compiler whose "const" support status is
different from the status of the compiler used to configure and
compile krb5?
Example: krb5 is compiled and build with gcc. The resulting libraries
are shipped as part of a product, and a customer wants to link against
them on an HP-UX 9 machine using the vendor cc. Alas, he can't,
because when he tries to include krb5 header files in his program,
he'll get errors from the compiler because it doesn't understand
"const".
Another example, in the other direction: Kerberos is compiled with the
vendor cc, because when it's compiled with gcc, it has trouble using
the system ndbm libraries. However, someone writing a C++ program
wants to use the Kerberos libraries, and therefore includes the
Kerberos header files in his program. Unfortunately, those header
files define "const" to nothing, which causes the "const" to be
removed from source code in the C++ program, which causes the C++
compiler to complain about type conflicts in function declarations
vs. their definitions.
I see several possible solutions to this problem:
1) Determine what to do with "const" at compile-time, not at
configure-time. This is a problem because there may be problems with
"const" that can't be detected at compile-time (which is probably why
configure was used in the first place to check for it).
2) Use "CONST" everywhere in the krb5 sources where "const" is used
now. Then, define "CONST" to "const" (which will either be left alone
or defined to nothing) when building the krb5 tree itself, but define
it to nothing outside of the krb5 tree. Unfortunately, this means
that function declarations used by outside callers to the krb5 API
won't have "const" on them, but that's a minor price to pay to make
the header files compatible with both ANSI and non-ANSI compilers.
3) Don't use "const" at all in the krb5 sources.
Any comments?
jik
