[1348] in Kerberos-V5-bugs
Re: krb5b4pl3: problems with "const" configuration and usage
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon Apr 24 13:46:24 1995
Date: Mon, 24 Apr 1995 13:46:07 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: "Jonathan I. Kamens" <jik@cam.ov.com>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: "[1347] in Kerberos-V5-bugs"
From: "Jonathan I. Kamens" <jik@cam.ov.com>
Date: Mon, 24 Apr 1995 12:23:39 -0400
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.
Actually, you only need to use the CONST hack in krb5.h (and associated
include files which are included in krb5.h); you don't actually need to
do that in the rest of the source tree.
What I'd actually suggest using a name like KRB5_CONST, and document
that on systems which are explicitly non-ANSI conformat, they should
"#define KRB5_CONST" to define away the "consts" in krb5.h. In general,
I think it's better to assume that you have an ANSI compiler, instead of
the other way around.
Aside from Ultrix, are there *that* many operating systems that have
non-ANSI compilers? The other possibility if there are still major OS's
that have non-ANSI compilers would be to put strategic #ifdef's into
krb5.h to try to automatically set KRB5_CONST if necessary. I hesistate
going into that business, though....
- Ted
