[krbdev.mit.edu #2836] feature request: compile/link timewarnings for deprecated functions

[Jeffrey Altman]

Ken Raeburn via RT wrote:

> (Not for 1.4, but maybe for consideration post 1.4...)
> 
> I've played around a little bit with producing warnings for code using
> functions we've marked as deprecated.
> 
> I see two possible approaches, both of which are specific to the GNU
> tools at least at the moment (though I think that covers a pretty good
> portion of our developer-user base).  Each has benefits and drawbacks.
> 
> * GCC "deprecated" attribute in declarations
> 
> This involves annotations in krb5.h, and produces warnings when a
> source file is compiled that uses a deprecated symbol.  (Actually, I
> haven't looked at whether it applies to non-function symbols, but I
> don't think we have many of those to worry about.)
> 
> The result looks like:
> 
> foo.c:3: warning: `old_fn' is deprecated (declared at foo.c:2)
> 
> In our source tree, we have quite a few references to
> krb5_c_random_seed, but also krb5_auth_con_initiivector and the
> get_in_tkt functions.  You can't offhand tell if the referencing code
> itself is marked as deprecated.  We should probably fix most of them
> anyways; if we can't implement our code without use of deprecated
> functions, how can we expect anyone else to?

In Windows there are two options for use with the Microsoft compilers:

	__declspec(deprecated) void func1(int) {
	};

and

	#pragma deprecated( identifier1 [,identifier2, ...] )

The pragma form supports the deprecation of function, type, or any other 
identifier.  To deprecate a macro symbol, the symbol is placed in double 
quotes.

Jeffrey Altman


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3256 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20041220/9dc36fe3/attachment.bin