obfuscated

J

jmcgill

Mark said:
No, this isn't required by the Standard, and indeed realworld
implementations will break this assumption (think non-english
character sets, or EBCDIC or whatever)

I was thinking of those, and I was under the impression that lexical
ordering was guaranteed, but I guess not.

Oh well, these obfuscated code examples are rarely meant to be good
examples of strictly conforming, portable C. Likewise, ACM programming
contest entries have to be just good enough to compile and run once on
the target platform :)
 
T

Thomas J. Gritzan

i am not hiding any macro definition
i actually got this question from my friend which was as follows::

The following code prints "I LOVE YOU".

main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Avoid the use of digit 1 in above code to print the same output.
Keep in mind not to use direct output text in the code :)

No problem, I replaced the "1" by "2":

int main(_,_o){for(_^=_;putchar(_++["Wlfgdklgf\"@gjctkmwp\b\2"]^2););}

Also it works with command line arguments. It still requires an ASCII
character set.
 
D

dcorbit

Thomas said:
i am not hiding any macro definition
i actually got this question from my friend which was as follows::

The following code prints "I LOVE YOU".

main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Avoid the use of digit 1 in above code to print the same output.
Keep in mind not to use direct output text in the code :)

No problem, I replaced the "1" by "2":

int main(_,_o){for(_^=_;putchar(_++["Wlfgdklgf\"@gjctkmwp\b\2"]^2););}

The data type of _o is wrong.
The main() function does not return a value.
Also it works with command line arguments. It still requires an ASCII
character set.

This should be portable to any system.

#include <stdio.h>
int _;
const char *__ =
"\117"
"\142"
"\146"
"\165"
"\163"
"\143"
"\141"
"\164"
"\145"
"\40"
"\143"
"\157"
"\162"
"\162"
"\145"
"\143"
"\164"
"\154"
"\171"
"\54"
"\40"
"\160"
"\154"
"\145"
"\141"
"\163"
"\145"
"\56"
"\n"
;
 
D

dcorbit

Ancient_Hacker said:
Hi all,

can anybody please explain why this code

main(_) {for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

is producing the output:: I love you


easy. Underscore is an allowed character in an identifier. main(_)
declares it as a parameter in place of argc. argc is 1, so if yo
decrement it, it starts out at zero.
That "J!... " string is just "I love you" with 1 added to each
character.

Of course, argc can be zero. There is no requirement in the C language
that argc is at least one and that argv[0] contains the program name.
It is possible for argc to be zero and argv[1] to be a null pointer.
 
C

Clark S. Cox III

Thomas said:
i am not hiding any macro definition
i actually got this question from my friend which was as follows::

The following code prints "I LOVE YOU".

main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Avoid the use of digit 1 in above code to print the same output.
Keep in mind not to use direct output text in the code :)
No problem, I replaced the "1" by "2":

int main(_,_o){for(_^=_;putchar(_++["Wlfgdklgf\"@gjctkmwp\b\2"]^2););}

The data type of _o is wrong.
The main() function does not return a value.
Also it works with command line arguments. It still requires an ASCII
character set.

This should be portable to any system.

[snip]

Still assumes an ASCII character set
 
D

dcorbit

A couple simple changes has turned this into a broken compiler test.
GCC Passes:

dcorbit@DCORBIT64 /mingw
$ cat broke_o.c
??=include <stdio.h>
int _;
const char *__ =
"\117""\142""\146""\165"
"\163""\143""\141""\164"
"\145""\40""\143""\157"
"\162""\162""\145""\143"
"\164""\154""\171""\54"
"\40""\160""\154""\145"
"\141""\163""\145""\56""\n";
/??/
* Comment carefully *??/
/
int main() ??<for (; putchar(_++ ??(__ ??)););return 0;??>

dcorbit@DCORBIT64 /mingw
$ gcc -Wall -ansi -pedantic broke_o.c
broke_o.c:1:1: warning: trigraph ??= converted to #
broke_o.c:11:2: warning: trigraph ??/ converted to \
broke_o.c:12:22: warning: trigraph ??/ converted to \
broke_o.c:14:12: warning: trigraph ??< converted to {
broke_o.c:14:32: warning: trigraph ??( converted to [
broke_o.c:14:36: warning: trigraph ??) converted to ]
broke_o.c:14:50: warning: trigraph ??> converted to }

dcorbit@DCORBIT64 /mingw
$ ./a
Obfuscate correctly, please.

dcorbit@DCORBIT64 /mingw
$

MS VC++ fails:
C:\mingw>cl /W4 /Ox broke_o.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42
for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.

broke_o.c
broke_o.c(15) : fatal error C1071: unexpected end of file found in
comment
 
D

dcorbit

Clark said:
Thomas said:
(e-mail address removed) wrote:
i am not hiding any macro definition
i actually got this question from my friend which was as follows::

The following code prints "I LOVE YOU".

main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Avoid the use of digit 1 in above code to print the same output.
Keep in mind not to use direct output text in the code :)
No problem, I replaced the "1" by "2":

int main(_,_o){for(_^=_;putchar(_++["Wlfgdklgf\"@gjctkmwp\b\2"]^2););}

The data type of _o is wrong.
The main() function does not return a value.
Also it works with command line arguments. It still requires an ASCII
character set.

This should be portable to any system.

[snip]

Still assumes an ASCII character set

Within a C source file, isn't ISO 646 character set assumed?
 
C

Clark S. Cox III

Clark said:
Thomas J. Gritzan wrote:
(e-mail address removed) wrote:
i am not hiding any macro definition
i actually got this question from my friend which was as follows::

The following code prints "I LOVE YOU".

main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Avoid the use of digit 1 in above code to print the same output.
Keep in mind not to use direct output text in the code :)
No problem, I replaced the "1" by "2":

int main(_,_o){for(_^=_;putchar(_++["Wlfgdklgf\"@gjctkmwp\b\2"]^2););}
The data type of _o is wrong.
The main() function does not return a value.

Also it works with command line arguments. It still requires an ASCII
character set.
This should be portable to any system.
[snip]

Still assumes an ASCII character set

Within a C source file, isn't ISO 646 character set assumed?

No.
 
P

Pedro Graca

Of course, argc can be zero. There is no requirement in the C language
that argc is at least one and that argv[0] contains the program name.
It is possible for argc to be zero and argv[1] to be a null pointer.
----------------------------------------------^

Do you mean
it is possible for argc to be zero and argv[0] to be a null pointer/
--------------------------------------------^
?

#include <stdio.h>

int main(int argc, char **argv) {
if (argc == 0) {
puts(argv[1]); /* BOOM: accessing one past end of array */
}
puts(argv[argc+1]); /* BOOM: accessing one past end of array */
return 0;
}
 
J

jmcgill

It is possible for argc to be zero and argv[1] to be a null pointer.

Because you cannot necessarily rely on main(int, char**) being called
the way you expect? Or something else? I have never considered this
before. But obviously there's nothing very special about main.
Anything that can get the appropriate linkage can call it with whatever
stack it wants, right?
 
R

Richard Heathfield

Pedro Graca said:
Of course, argc can be zero. There is no requirement in the C language
that argc is at least one and that argv[0] contains the program name.
It is possible for argc to be zero and argv[1] to be a null pointer.
----------------------------------------------^

Do you mean
it is possible for argc to be zero and argv[0] to be a null pointer/

Yes, that's what he means. argv[argc] is NULL by definition.
 
R

Richard Heathfield

jmcgill said:
I was thinking of those, and I was under the impression that lexical
ordering was guaranteed, but I guess not.

EBCDIC's okay with the ordering, but the alphabets are non-contiguous,
coming as they do in rows of ten on boundaries of sixteen.
 
M

Mark McIntyre

I was thinking of those, and I was under the impression that lexical
ordering was guaranteed, but I guess not.

Probably doesn't work too well in any character set pertaining to
cyrillic, greek, chinese, arabic, hebrew, turkish, etc etc.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
M

Mark McIntyre

It is possible for argc to be zero and argv[1] to be a null pointer.

the zeroth argument of main() is reserved for the program name, but an
implementation is not obligated to populate it. In an embedded
environment, there would be no need to.

Plus you can call main recursively in C.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
S

Simon Biber

Mark said:
Probably doesn't work too well in any character set pertaining to
cyrillic, greek, chinese, arabic, hebrew, turkish, etc etc.

All of those character sets still have lexical ordering of Latin letters
A to Z. They are almost always built on ASCII as a base and use the
characters with high bit set to encode all the other required characters
(sometimes in pairs or quads). This is the case with ISO-8859 series,
ISO-2022 series, EUC series, Shift-JIS, GB2312, GB18030, Big5,
Big5-HKSCS, etc.

As for lexical ordering of other alphabets in their own charsets, that
varies. Some languages don't even have a well-defined ordering. There
are several possible sort orders for Chinese characters (based on
radicals, pronunciation or number of strokes).
 
M

Mark McIntyre

All of those character sets still have lexical ordering of Latin letters
A to Z

Chinese doesn't have any latin letters, its all pictures. Greek goes
abgde etc. Arabic doesn't use ASCII letters. etc.
. They are almost always built on ASCII as a base

I fear you're thinking of national extensions to ISO-646.
As for lexical ordering of other alphabets in their own charsets, that
varies. Some languages don't even have a well-defined ordering.

Absolutely.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan
 
S

Simon Biber

Mark said:
Chinese doesn't have any latin letters, its all pictures. Greek goes
abgde etc. Arabic doesn't use ASCII letters. etc.

I was referring to lexical ordering of Latin letters, not of other
characters. Chinese character sets DO have the full set of Latin
letters, alongside all the Chinese characters. So do Arabic character
sets. I am yet to see one that does not provide all the Latin letters
alongside the Arabic ones. And the Latin letters are in lexical order A
- Z. I said nothing about the ordering of the Arabic letters or Chinese
characters.
I fear you're thinking of national extensions to ISO-646.

No, I'm referring to the specific character sets I mentioned.
 
D

Dave Thompson

jmcgill said:


EBCDIC's okay with the ordering, but the alphabets are non-contiguous,
coming as they do in rows of ten on boundaries of sixteen.

s/ten/nine and eight (averaging 8.6overbar)/

But you do rhyme with 'seas of green', FWIW.


- David.Thompson1 at worldnet.att.net
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top