Ticket History #2836: feature request: compile/link time warnings for deprecated functions

(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?


* GNU linker warnings

On ELF systems, the GNU linker will emit any message stored in an ELF
section .gnu.warning.<symname> if <symname> is referenced. With gcc,
an asm statement in the source file defining the deprecated function
is the best way to produce that section. (Similar hacks can be done
for a.out/stabs systems, if we care.) The asm ickiness can be hidden
in a small macro in k5-platform.h quite easily, so the library source
files just have macro invocations.

Minor annoyance: To avoid empty top-level declarations in the case
where this functionality isn't supported, the macro invocation should
*not* be followed by a semicolon. This makes the Emacs indentation
code a bit unhappy.

With this approach, we get control over the warning message text.
This is good in that we can cause the text to recommend a replacement
function, but less than ideal from an i18n perspective, where gcc
emits locale-specific messages and then we dump out a string in
English.

Object files and libraries built with other tools but linked with the
GNU linker against gcc-compiled krb5 libraries would still have checks
done. Well, for object files linked in; a deprecated, unused object
file in an archive library that references deprecated krb5 functions
wouldn't produce a warning.

One possibly serious drawback: An object file with two functions, one
used by the application and the other, unused one referencing a
deprecated symbol, can produce a warning during static linking. In a
static build in our tree, warnings about old_api_glue.c references to
krb5_c_random_seed are common. If we still care that much about
static linking, and want link-time warnings, we could split out any
such references that we can't eliminate into separate source files.

The result of my sample implementation looks like:

kprop.o(.text+0x44e): In function `get_tickets':
../../src/slave/kprop.c:301: warning: krb5_get_in_tkt_with_keytab is deprecated; use krb5_get_init_creds_keytab

I don't know if uses of dlopen/dlsym will emit the warnings.


* Facilities in other (non-GNU) toolchains?

I don't know about any such facilities in other compiler toolchains we
use; if anyone does, I'd be interested to hear about them, to see
whether we might be able to make use of them as well.



In test builds of the current tree on Linux with the attached patch,
the attribute caused 18 compile-time warnings; the linker emitted 10
warnings in a shared-library build, and 80 in a static-library build,
with old_api_glue.c causing most of the extra warnings in the static
case.

Ken