[Solved] GCC C Ternary conditional operator

[encryptor256]

Hayo!

Look what I found.
C Ternary conditional operator failure or parser error - who knows.
C Ternary conditional operator is/was: A ? B : C
It doesn't matter about the code, but about LOGIC.

This code works compiled with compiler named: Tiny C Compiler.
This code is not working compiled with GCC, even Online Compiler.

Code fragment: (Works on Tiny C, Doesn't works on GCC)

Code: [Select]

if(*node!=0)
{
return TernaryNode_add(((*node)->value < *name) ? &(*node)->left : ((*node)->value == *name) ? &(*node)->middle : &(*node)->right,++name,data);
};

Problem is that - gcc it seems does not parse that Ternary operator correctly.

GCC compatible version of code? - YES!

This is GCC compatible version that works:

Code: [Select]

if(*node!=0)
{
TernaryNode ** test = ((*node)->value < *name) ? &(*node)->left : ((*node)->value == *name) ? &(*node)->middle : &(*node)->right;
return TernaryNode_add(test,++name,data);
};

Function TernaryNode_add description:
Function adds a word to a Ternary tree.
Returns (-1) on managed error or if a word exists already.
Returns (0) on success - word added.

Original code:
I am creating a Ternary tree to add words.
While creating I found that Ternary C operator is not working in the way you see above - It does not parses it correctly if that my ternary operator thingy is put in first argument (Maybe it's too large or too boring for gcc).
I am adding two equal words, gcc produces error but other compiler result is correct.

You can try it your self with that online compiler link provided above, files are attached here below.

If code works it must print:

Code: [Select]

(rvalue: -1)
All Right, All Left!Bame

Rvalue is -1 because I tried to add one word twice.

Edit:
Bye, don't use GCC if you still have hairs on hour head.

[SOLVED] Bye, GCC is awesome! 

Edit, again:
SOLVED, LRESULT: Paremeter Evaluation Issue of C (Left to Right or Right to Left)

[encryptor256]

Okay, I found the problem.

Compiling code with "gcc.exe -Wall -Wextra" it throws warning "warning: operation on 'name' may be undefined".

Operation on X may be undefined - so, do I care? It's 21th century and compiler has to know what I want even before I type.

This information from IBM fully explains how to fix that: Undefined operation on a pointer variable

I found that answer through other forum on linuxquestions from user "kbp": warning: operation on 'i' may be undefined [-Wsequence-point]

Bye.

[Rob Neff]

I'm assuming that your use of the pre-increment ( ++name ) in the first example is why the issue occurs.

With pre-increment, the variable will be incremented and then used for the evaluation. With post increment, it is used at its current value and then incremented after the expression is evaluated.

Did you intend for name to point to new data prior to evaluation?  If not, then the "bug" introduced was caused by you.

[encryptor256]

I'm assuming that your use of the pre-increment ( ++name ) in the first example is why the issue occurs.

With pre-increment, the variable will be incremented and then used for the evaluation. With post increment, it is used at its current value and then incremented after the expression is evaluated.

Did you intend for name to point to new data prior to evaluation?  If not, then the "bug" introduced was caused by you.

Thanks for the answer, Rob.

Did you intend for name to point to new data prior to evaluation?

Well I wanted for name to point to new data only when it calculates second argument for a function call.
So, when it calculates first argument name is as it is, but when it calculates-stores second argument it
have to increment address of name and pass it to next function call.



Bye
Encryptor256

[encryptor256]

Version 2

So, here I made and investigated one more version.

Code: [Select]

#include <stdio.h>
#include <stdlib.h>

void myfunc(unsigned char lastchar, const char * text)
{
if(text==0||*text==0) return;


if(lastchar!=0)
{
printf("%c",lastchar);
};


myfunc(*text == '0' ? 'A' : 'B',++text);
};

int main(void)
{
myfunc(0,"010101");
return 0;
};

Output:

Code: [Select]

BABAB

Output is wrong, it has to be "ABABA".

Q: Why is it wrong?
A: It is wrong because it seems, that it calculates second argument at first priority. So basically it calculates arguments from right side OR last first.

It has to calculate arguments starting in the way they are filled, so
we call functions starting argument filling from first argument.

myfunc(*text == '0' ? 'A' : 'B',++text);

Wrong:
At first it updates-increments text address.
Then it evaluates first argument: "*text == '0' ? 'A' : 'B'".

This is wrong, C is wrong, My thinking is right!

At first it has to evaluate first argument: "*text == '0' ? 'A' : 'B'".
Then it has to evaluate second argument: "++text".
Then it has to call that function.

All Right, All Left.

Encryptor256!

Edit:

Report from: Encryptor256's Investigation \ Research Department.

Haye!

This problem actually is a common one.

Parameter evaluation order before a function calling in C

• "They" confirm, parameters are evaluated from right to left. (Who knows)
• So, it seems it is a sensitive theme to discuss.
• It looks like that they are close to start fighting, one says - one thing, other - other thing

Well, no wonder I found this issue - common one!

Thanks, bye!