Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RT-Original-Encoding: us-ascii Content-Length: 1569 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