[libvirt] [PATCH] Domain/Net object cleanups after remote error

[Jim Meyering]

"Richard W.M. Jones" <rjones at redhat.com> wrote:

> On Tue, May 20, 2008 at 03:38:01PM +0100, Daniel P. Berrange wrote:
>> So I vote for applying all Cole's patches which do indeed fix a number
>> of memory leaks. Fixing the daemon to correctly serialize errors with
>> a dom/net object can be done later unless someone has burning desire
>> to tackle it now
>
> Those fields are nothing but trouble.  Any chance we can make a
> special exception and get rid of them in a way which causes code that
> depends on them to compile-fail with a meaningful error message, and
> yet doesn't break old running code linking to a newer library?

Hi Rich.
Good idea.

As a matter of fact, with gcc, there is a way to do that
for variables.  I'd seen this applied to functions, but not
to variables.  From gcc's extend.texi:

    @cindex @code{deprecated} attribute
    The @code{deprecated} attribute results in a warning if the variable
    is used anywhere in the source file.  This is useful when identifying
    variables that are expected to be removed in a future version of a
    program.  The warning also includes the location of the declaration
    of the deprecated variable, to enable users to easily find further
    information about why the variable is deprecated, or what they should
    do instead.  Note that the warning only occurs for uses:

    @smallexample
    extern int old_var __attribute__ ((deprecated));
    extern int old_var;
    int new_fn () @{ return old_var; @}
    @end smallexample

So I tried it and it works like a charm:

    $ cat k.c
    struct foo {
      int ii;
      int jj __attribute__((deprecated));
    };
    static int
    bar()
    {
      struct foo o;
      o.jj = 1;
    };
    $ gcc -c k.c
    k.c: In function 'bar':
    k.c:9: warning: 'jj' is deprecated (declared at k.c:3)