"Richard W.M. Jones" <rjones@xxxxxxxxxx> 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)
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list