logical OR obfuscation

[Mantorok Redgormor]

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition

 

[pete]

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition

if (!(!a && !b))

 

[Tristan Miller]

Greetings.

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition

if (a)
do_something();
if (b && !a)
do_something();

or

if (a||b||!(really_complicated_expression))

where really_complicated_expression is a tautology (i.e., necessarily true).

There are an infinite number of variations.

 

[Robert Stankowic]

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition

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

int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}


int hide_and(int a, int b)
{
int c = 0;
if(a)
{
if(b)
{
c = 1;
}
}
return c;
}


int main(void)
{
int a = 0;
int b = 0;
int c;

c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 0;
b = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
return EXIT_SUCCESS;
}

Robert

 

[CBFalconer]

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition

if (!(!a && !b)) ;
else {
/* whatever */
}

 

[Robert Stankowic]

Greetings.



if (a)
do_something();
if (b && !a)
do_something();

This is not an exact equivalent, because it does not account for the lazy
evaluaton.

cheers
Robert

 

[Ed Morton]

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition

if (a ? 1 : (b ? 1 : 0)) {
do something
}

Regards,

Ed.

 

[Ricardo Gibert]

Greetings.



if (a)
do_something();
if (b && !a)
do_something();

Caution: This assumes the first "do_something()" does not have a side effect that can change a or b.

or

if (a||b||!(really_complicated_expression))

where really_complicated_expression is a tautology (i.e., necessarily true).

There are an infinite number of variations.

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

 

[Darrell Grainger]

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition

Yes. The ||, && and ! come from boolean logic. Any introduction to boolean
logic will teach you to write OR in terms of AND and NOT.

More importantly, why would you want to?

 

[Robert Stankowic]

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

int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}


int hide_and(int a, int b)
{
int c = 0;
if(a)
{
if(b)
{
c = 1;
}
}
return c;
}


int main(void)
{
int a = 0;
int b = 0;
int c;

c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 0;
b = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
a = 1;
c = hide_or(a, b);
printf("%d %d %d ", a, b, c);
c = hide_and(a, b);
printf("%d %d %d\n", a, b, c);
return EXIT_SUCCESS;
}

Oops, this does not emulate the lazy evaluation
sorry

 

[Joe Wright]

if (!(!a && !b))

Now I know you, pete de Morgan. Very good.

 

[Robert Stankowic]

sorry, the code did not correctly deal with side effects and lazy evaluation
(
maybe this one is better

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

int foo;

int bar(int val)
{
foo++;
return val;
}

int baz(int val)
{
foo++;
return val;
}

void do_something(void)
{
}

int main(void)
{
int i;
int j;

for(i = 0; i < 2; i++)
{
for(j = 0; j < 2; j++)
{
foo = 0;
if(bar(i))
{
do_something();
continue;
}
if(baz(j))
{
do_something();
}
}
}

for(i = 0; i < 2; i++)
{
for(j = 0; j < 2; j++)
{
foo = 0;
if(bar(i))
{
if(baz(j))
{
do_something();
}
}
}
}

return EXIT_SUCCESS;
}
Robert

 

[Noah Roberts]

Can emulation of the logical OR be done in standard C to obfuscate its
use? So I don't have to use if(a||b) but instead make that even more
obfuscated without its use but testing the same condition

#define BLUE_MEANIES ||

if (a BLUE_MEANIES b) ...

NR

 

[Martijn]

int hide_or(int a, int b)
[remaining code snipped]

Oops, this does not emulate the lazy evaluation
sorry

I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

I'm not sure, but might still have some side effects, though.

 

[Christian Bau]

[remaining code snipped]

Oops, this does not emulate the lazy evaluation
sorry

I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

I'm not sure, but might still have some side effects, though.[/QUOTE]

If you _call_ the function, both arguments that you pass will be
evaluated before they are passed to your function. Example:

int test1 (int* p) { return p == NULL || *p == 0; }
int test2 (int* p) { return hide_or (p == NULL, *p == 0); }

The second function will crash if you call it with a null pointer as its
argument because it will evaluate *p. There is no "lazy" evaluation here
at all.

 

[pete]

[remaining code snipped]

Oops, this does not emulate the lazy evaluation
sorry

I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

I'm not sure, but might still have some side effects, though.

I don't see any side effects.

N869
5.1.2.3 Program execution
[#2]
Accessing a volatile object,
modifying an object,
modifying a file,
or calling a function that does any of those operations
are all side effects,
which are changes in the state of the execution environment.

 

[Robert Stankowic]

int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}

[remaining code snipped]

Oops, this does not emulate the lazy evaluation
sorry

I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

No, because if the function is called, both arguments, which can cause
side-effects, are evaluated, in if(a || b) only if a yields 0.

I'm not sure, but might still have some side effects, though.

I don't see any side effects.

N869
5.1.2.3 Program execution
[#2]
Accessing a volatile object,
modifying an object,
modifying a file,
or calling a function that does any of those operations
are all side effects,
which are changes in the state of the execution environment.

If the function is called with for example
hide_or(foo(), bar());
foo() and bar() are both called, in if(foo() || bar()){} only if foo()
returns 0.
I am totally sure you know that

regards
Robert

 

[pete]

int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}

[remaining code snipped]

Oops, this does not emulate the lazy evaluation
sorry

I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

No, because if the function is called, both arguments, which can cause
side-effects, are evaluated, in if(a || b) only if a yields 0.

I'm not sure, but might still have some side effects, though.

I don't see any side effects.

N869
5.1.2.3 Program execution
[#2]
Accessing a volatile object,
modifying an object,
modifying a file,
or calling a function that does any of those operations
are all side effects,
which are changes in the state of the execution environment.

If the function is called with for example
hide_or(foo(), bar());
foo() and bar() are both called, in if(foo() || bar()){} only if foo()
returns 0.
I am totally sure you know that

.... or even

hide_or(a++, b);

Those side effects are from the function *call*.
They are not side effects from the function.
Some functions, like memset(), have side effects.
The function defined above, has no side effects.

 

[Robert Stankowic]

Martijn wrote:

int hide_or(int a, int b)
{
int c = 0;
if(a)
{
c = 1;
}
if(b)
{
c = 1;
}
return c;
}

[remaining code snipped]

Oops, this does not emulate the lazy evaluation
sorry

I'd would if you'd write:

int hide_or(int a, int b)
{
if (a)
return 1;
if (b)
return 1;

return 0;
}

No, because if the function is called, both arguments, which can cause
side-effects, are evaluated, in if(a || b) only if a yields 0.

I'm not sure, but might still have some side effects, though.

I don't see any side effects.

N869
5.1.2.3 Program execution
[#2]
Accessing a volatile object,
modifying an object,
modifying a file,
or calling a function that does any of those operations
are all side effects,
which are changes in the state of the execution environment.

If the function is called with for example
hide_or(foo(), bar());
foo() and bar() are both called, in if(foo() || bar()){} only if foo()
returns 0.
I am totally sure you know that

... or even

hide_or(a++, b);

Those side effects are from the function *call*.
They are not side effects from the function.
Some functions, like memset(), have side effects.
The function defined above, has no side effects.

Ah, OK, my misunderstanding - I had the whole code in mind.
In the context of the function only you are right of course

regards
Robert

 

[Tom Zych]

pete wrote:

Now I know you, pete de Morgan. Very good.

He prefers to be called "Captain" de Morgan. Arrr!