obfuscated

Hi all,

can anybody please explain why this code

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

is producing the output:: I love you


1) what is this under score stuff inside main parenthesis?
2) what does this --_ mean in the initialization condition of for
loop
3) what is the role of this operator _ (unary minus i presume) in
putchar

re: obfuscated

<aarklon@gmail.comwrote in message
news:1160491963.336532.175830@m73g2000cwd.googlegr oups.com...Not without seeing all of it.
No, it's not an operator at all. It's probably a macro whose
definition you're not showing us.

-Mike

re: obfuscated

aarklon@gmail.com wrote:I'll bite. I might be wrong, but I'll bite.
It is an illegal (I presume) reference to something like argc. It is
similar to "main(int _)", but very non-standard.

I expect for those compilers that accept this will set "_" to 1 before
we visit the for loop.
It predecrements the C identifier "_".
It is not an operator. It is equivalent in ways that count (standard or
not) to "int _".

So, we loop through the char array, getting the _th item in the array,
subtracting 1 and printing the char we get. I suppose this presumes
ASCII collation.

re: obfuscated

aarklon@gmail.com wrote:
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.

re: obfuscated

Clever Monkey wrote:(Depending on how this code is run, of course. Try running the
executable with arguments and see what happens...)

re: obfuscated

Mike Wahler wrote:
That /is/ all of it.
It's the first (and only) argument to `main`. The program has to
be run with no arguments (each argument will ignore another
leading output character, that is if the undefined behaviour [1]
doesn't lead to metapsychic meltdown or penguins at Southend).

It's a bit obvious, really. If it weren't for Yet More Undefined
Behaviour, `_++["J!Mpwf!Zpv\1"]+_` would be better [2], with
appropriate adjustments to the string.

[1] I assume undefined behaviour because `main` wasn't declared in
one of the Two Allowed Ways. And of course it relies on ascii
character codes.

[2] For values of `better` that are ... um ... er ...

--
Chris "Essen -9 and counting" Dollin
Nit-picking is best done among friends.

re: obfuscated

aarklon@gmail.com wrote:'_' is an argument of main, which is int; '--_' means decrease '_'
first.

The argument of putchar() can be rewritten as

("J!Mpwf!Zpv\1"[_++] )-1

, which is a char in the string "J!Mpwf!Zpv\1".

re: obfuscated

<aarklon@gmail.comwrote in message
news:1160491963.336532.175830@m73g2000cwd.googlegr oups.com...All right, let's start:
the '_' identifier is used instead of the more well known argc.
Also, the a[1]=1[a] idiom is used.
So, let's
change the program to a more readable version:

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

well, not much more readable, but now we can understand it:
argc has the value 1 when the program starts, so, when the
for starts, argc will be 0.

Now, while the putchar("...") does not return 0, the loop
will be executed each time and the value of argc will be
increased. And, considering that : J-1 = I, !-1=' '(space),
M-1 = L etc you see how I Love you is printed.

Last point: Why does the loop stop ? Because '\1' - 0 =0,
so, putchar will return 0 and the loop will exit :)

Serafeim Papastefanos

re: obfuscated

Mike Wahler 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 :-)

re: obfuscated

Mike Wahler wrote:That's all of it. It's not all that strange.
The mapping of the data to the output is obvious.

_ gets the argc value. It gets decremented. It then is used as an
array index (because n[a] is equivalent to a[n]), and each element of
the array is decremented by one. When it gets to '\0', putchar returns
0 and the for loop ends.

re: obfuscated

Clever Monkey wrote:
Shouldn't a non-ASCII implementation do the right thing, where 'b' -1 =
'a', regardless of the inner details?

re: obfuscated

jmcgill <jmcgill@email.arizona.eduwrote:
No. Read the Standard. Only '0'...'9' are required to be subsequent. The
rest need not, and often _but not always_ is subsequent.

Richard

re: obfuscated

Aarklon posted:

(1) If we replace the underscore object name with "i", then we get:

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


(2) If we make explicit the implicit int:

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


(3) If we put in white space to make things prettier:

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


(4) If we take "i" out of the loop, and then change it to a "while" loop:

int main(int i)
{
--i;

while( putchar(i++["J!Mpwf!Zpv\1"]-1); );
}


(5) If we change "index[array]" to "array[index]", then we have:

int main(int i)
{
--i;

while( putchar( "J!Mpwf!Zpv\1"[i++] - 1) );
}


(6) If we take the take the string out of the loop to make it clearer:

int main(int i)
{
char const str[] = "J!Mpwf!Zpv\1";

--i;

while (putchar(str[i++] - 1));
}

Armed with the knowledge that "putchar" returns the char it prints, we can
see that we are iterating through each character of the string, subtracting
one from it, then printing it.

The code is non-portable as it makes the unfounded presumption that:

'J' == 'I'+1

Also, I'm not sure if that's a valid signature for "main".

--

Frederick Gotham

re: obfuscated

Clever Monkey wrote:Actually, the function definition form
foo(arg) {}
Is entirely legal and standard C89 since C89 still allows implicit int
and old K&R style function definitions. The problem is that main takes 0
or 2 arguments, not one. This could be fixed by changing it to

main(_,__)char**__;{for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
which still keeps it obfusticated.

You can get C99 compliance with
#include<stdio.h>
int main(_,__)int
_;char**__;{for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
<snip>

Unless the user supplies parameters or the environment chooses not to
pass something as the "program name".
--
Flash Gordon

re: obfuscated

Flash Gordon wrote:Sure. This is what I meant by "non-standard", since the main() is
malformed and incorrect with respect to the standard. I do understand
that this is a _mostly_ legal function definition; just not for the
function main(). Note my reference to "argc", above.

Furthermore, wasn't there just a thread here about the use of "_" and
"__" being forbidden by the standard under most circumstances? I
suppose an identifier that consists only of these characters would be
contrary to that rule, as well.

Again, this does not speak to the OP, but it indicates that many things
about "main(_)" are probably wrong, regardless of the fact that main()
can be treated just like another function in many cases and that the
default type for untyped identifiers is int.

re: obfuscated

aarklon@gmail.com wrote:It doesn't produce that output. The L and Y are capitalised.

If you supply arguments to the program, one letter is lost from the
beginning for each argument you supply. If you supply more than 10
arguments, the program outputs garbage until a 1 byte is found in memory
or the program attempts to read an invalid address and is terminated.


C:\docs\prog\c>type aarklon.c
#include <stdio.h>
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

C:\docs\prog\c>tcc aarklon.c
Turbo C Version 2.01 Copyright (c) 1987, 1988 Borland International
aarklon.c:
Turbo Link Version 2.0 Copyright (c) 1987, 1988 Borland International

Available memory 394258

C:\docs\prog\c>aarklon 1 2 3 4 5 6 7 8 9 0 1
↕☺☺♥♦♣‼¶♦↕â–*§♦►☺â–*â–*â –*â–*â–*â–*â–*â–*â–*â–*â–*â–*â–*♦♦â–*â–*â–*â–* â–*â–*â–*â–*â–*â–*â–*â–*â–*â–*â–*â–*♫â–*"☺â–*â ™«â–*â–*â–*â–*↕â–*â–*☺☺♦♫☺â–*â–*â–*↕ â–*â–*â–*â–*â–*â–*â–*â–*
"â–*â–*â–*â–*"â–*↕â–* z☺z☺z☺ ☼ ☺ ‼☺

--
Simon.

re: obfuscated

Frederick Gotham wrote:

Ah yes, any computers out there using the 5-bit Baudot code are going
to print complete gibberish.

Seriously, in IBM EBCDIC, the letters are not contiguous, due to it
being derived from BCD card codes, which as everybody knows, had nine
rows, so the letters are in groups of nine, with seven codes in between
to pad to the next multiple of 16.

But due to pure chance, most of the letters in this phrase are
comfortably away from the abrupt jumps. The only problem is with the
initial "J", which one less than is "}".


Also space is not just before exclamation point, Ampersand is. Also
the ending period gets messed up.

So in EBCDIC it will print out:

}&love&you|

re: obfuscated

Ancient_Hacker posted:

Exactly (assuming Baudot code has at least 3 unused bits).


Your use of "Seriously" is not necessary here at comp.lang.c, nor is it even
necessary to provide an example (although I'm glad you did :) ). All we need
to hear is "The Standard doesn't impose such a restriction" and we're bought.

--

Frederick Gotham

re: obfuscated

Clever Monkey wrote:OK, then we are in agreement about what is and is not valid.
You are right, I should not have used __. Perhals _l or _L would be
sufficiently obscure. That will teach me to rely on memory for a rule
like this. Normally I just don't start identifiers with an _ even where
it would be legal.
Well, the _ on its own is acceptable as an identifier as long as it is
not a file scope identifier which it isn't.
--
Flash Gordon

re: obfuscated

On Tue, 10 Oct 2006 08:41:07 -0700, in comp.lang.c , jmcgill
<jmcgill@email.arizona.eduwrote:
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)
--
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

re: obfuscated

Mark McIntyre wrote:
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 :-)

re: obfuscated

aarklon@gmail.com wrote: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.

--
Thomas
http://www.netmeister.org/news/learn2quote.html

re: obfuscated

Thomas J. Gritzan wrote:The data type of _o is wrong.
The main() function does not return a value.
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"
;
int main() ??<for (; putchar(_++ ??(__ ??)););return 0;??>

re: obfuscated

Ancient_Hacker wrote: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.

re: obfuscated

dcorbit@connx.com wrote:[snip]

Still assumes an ASCII character set

--
Clark S. Cox III
clarkcox3@gmail.com

re: obfuscated

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

re: obfuscated

Clark S. Cox III wrote:Within a C source file, isn't ISO 646 character set assumed?

re: obfuscated

dcorbit@connx.com wrote:No.

--
Clark S. Cox III
clarkcox3@gmail.com

re: obfuscated

dcorbit@connx.com writes:[snip]Certainly not. For example, EBCDIC-based systems are allowed and not
uncommon.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

re: obfuscated

dcorbit@connx.com wrote:----------------------------------------------^

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;
}

--
File not found: (R)esume, (R)etry, (R)erun, (R)eturn, (R)eboot

re: obfuscated

Clark S. Cox III wrote:Even if it where, characters in constants and literals get mapped to
the execution character set anyway.

--
Peter

re: obfuscated

dcorbit@connx.com wrote:
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?

re: obfuscated

Pedro Graca said:
Yes, that's what he means. argv[argc] is NULL by definition.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

re: obfuscated

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

re: obfuscated

On Tue, 10 Oct 2006 14:51:32 -0700, in comp.lang.c , jmcgill
<jmcgill@email.arizona.eduwrote:
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

re: obfuscated

On Tue, 10 Oct 2006 20:19:14 -0700, in comp.lang.c , jmcgill
<jmcgill@email.arizona.eduwrote:
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

re: obfuscated

Mark McIntyre wrote: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).

--
Simon.

re: obfuscated

On Thu, 12 Oct 2006 05:58:39 +1000, in comp.lang.c , Simon Biber
<news@ralmin.ccwrote:
Chinese doesn't have any latin letters, its all pictures. Greek goes
abgde etc. Arabic doesn't use ASCII letters. etc.
I fear you're thinking of national extensions to ISO-646.
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

re: obfuscated

Mark McIntyre wrote: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.
No, I'm referring to the specific character sets I mentioned.

--
Simon.

re: obfuscated

On Wed, 11 Oct 2006 06:14:35 +0000, Richard Heathfield
<invalid@invalid.invalidwrote:
s/ten/nine and eight (averaging 8.6overbar)/

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


- David.Thompson1 at worldnet.att.net

re: obfuscated

On 10 Oct 2006 11:54:37 -0700, "Ancient_Hacker" <grg2@comcast.net>
wrote:
Not to mention that 'Baudot' (officially IA2, the International
(Teletype) Alphabet #2): does not have lowercase letters and several
punctuation or 'special' characters that are required in the basic
(minimum) execution character set; has codes for the digits that are
not consecutive as required, as well as being shift-state dependent
which may not be specifically prohibited but doesn't make sense for
the ctype.h functions.
Cards had nine digit rows plus three zone rows, twelve total; usually
only 0 and 1-9 were printed. "Bury me face down, 9 edge first."

- David.Thompson1 at worldnet.att.net

re: obfuscated

Dave Thompson said:
Yes, I was relying on my (obviously faulty) memory. Later, I had occasion to
look the table up, and noted that the alphabet was in nines rather than
tens, but by then I didn't recall having claimed otherwise. :-)
Cue the solo on something brassy (tuba?).

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

re: obfuscated

Dave Thompson <david.thompson1@worldnet.att.netwrote:Ten digit rows -- 0 can be either a zone or a digit, depending on the
particular usage.

-Larry Jones

I won't eat any cereal that doesn't turn the milk purple. -- Calvin