gcc feature deprecation question

itsme86 · 07-09-2004, 01:31 PM

Hi, I'm using gcc-3.3.4 and I get a warning with the following code that I don't quite understand:

Code:

#include <stdio.h>

void myfunc(int *a)
{
  printf("%d\n", *a);
}

int main(void)
{
  int a = 1, b = 2;

  myfunc(&(a == 1?a:b));

  return 0;
}

The warnings I get are:

Quote:

$ gcc -Wall foo.c -o foo
foo.c: In function `main':
foo.c:12: warning: use of conditional expressions as lvalues is deprecated
foo.c:12: warning: use of compound expressions as lvalues is deprecated

If I change myfunc(&(a == 1?a:b)); to myfunc(&(1?a:b)); I don't get the warnings.

I know that the code I pasted is completely useless, but I use that conditional test to pass arguments to functions sometimes. My question is why would something like that be deprecated? I can't find anything in the announcements at http://gcc.gnu.org that say that it will be deprecated.

On another machine running gcc-3.2.3 I don't get the warnings using that same code.

Any insight would be appreciated. Thanks!

aluser · 07-09-2004, 02:10 PM

you should be able to do

Code:

myfunc(a == 1 ? &a : &b);

to get the effect you want without warnings. To me that reads more clearly anyway. I think the idea behind the deprecation is that by the time the ?: operator is evaluated, you're left with a simple value, not a variable, and so you can't necessarily take the address of it. e.g.

Code:

myfunc(&(a == 1 ? a : 3));

doesn't look fundamentally different from your original, yet it might turn out to be &3, which makes no sense.

itsme86 · 07-09-2004, 02:51 PM

That makes sense and it does work if I try your suggestion, but it still doesn't make sense that &(1?a:b) doesn't give the message since it could still resolve to something like &(1?a:3).

But anyway, distributing the ampersand to the variables is a fine fix for me. Thanks for the help

aluser · 07-09-2004, 03:33 PM

I'm guessing that &(1?a:b) is either a pseudo-bug or pseudo-feature. It could be that it gets optimized to &a before the part that checks for the deprecation gets to it. (In other words, the fact that the part before the ? is constant could lead gcc down a different code path.)