471,585 Members | 1,600 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,585 software developers and data experts.

How to understand this line of c ?

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

Dec 31 '05 #1
56 2644
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


Don't. It's rubbish.
--
Ivan Budiselic
ICQ# 104044323
IRC: buda @ #gamer.hr@quakenet
remove 'remove' for reply
Dec 31 '05 #2
lnzju wrote:
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


Some hints:

* Write the program with the correct tabulation
* Take into account that usually main parameters are argc and argv, but
they can be called with any name. And, if type is not declared K&R
assumes int.
* _ can be the name of a variable.
* Split "for" in its parts: a for statement is divided in
initialization, continue condition and update of state. The first one
and third ones can be empty.
* putchar returns the character written as unsigned int
* integer applied to string returns n-th element. (this is something I
do not know why).

Kind regards.

Dec 31 '05 #3
Ivan Budiselic wrote:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


Don't. It's rubbish.


Well it ain't rubbish cause it is valid C!!
Try compiling it..

The output will be:

I Love You

But this code is obfuscated.... Only the real C gurus will understand it
I Guess.... not this novice guy...

Broeisi
Dec 31 '05 #4
Even when "gcc" compiled with the flags -ansi and -pedantic, it
produces no errors nor warnings. Only with -std=c99 it produces 3
warnings.

Dec 31 '05 #5
"Broeisi" <br*******@gmail.com> wrote in message
news:Q-******************************@casema.nl...
Ivan Budiselic wrote:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Don't. It's rubbish.


Well it ain't rubbish cause it is valid C!!
Try compiling it..

The output will be:

I Love You


Maybe on your machine. Certainly not on all.
But this code is obfuscated.... Only the real C gurus will understand it
I Guess.... not this novice guy...


There's nothing guruesque about it.

--
Ivan Budiselic
ICQ# 104044323
IRC: buda @ #gamer.hr@quakenet
remove 'remove' for reply
Dec 31 '05 #6

"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


Here it is a little clearer [hopefully?]

#include <stdio.h>

// x will be 1 (the name of this app would be in argv[0]) if we
// don't invoke the app with some args.
//
main(x)
{
char c;

// zero then!
//
--x;

while(c = "J!Mpwf!Zpv\1"[x])
{
// No need for the -1 if we add 1 to the literal's characters...
//
// "I Love You\1"
//
c = c - 1;

x++;

putchar(c);
}
}
Dec 31 '05 #7

"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


Ah, but run it with some params, and it's dissapointing. Perhaps the
initialiser in the for loop would have been better this way?

for(_^=_; putchar(_++["J!Mpwf!Zpv\1"]-1); );
Dec 31 '05 #8
"lnzju" <ge*******@gmail.com> wrote:
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


The two following code fragments are equivalent:

/*-A-----------------------------------*/

#include <stdio.h>

int main(void)
{
char rubbish[] = "J!Mpwf!Zpv\1"; /* will 'print' trailing '\0' */
char *rp = rubbish;

while (*rp)
{
putchar ((*rp)-1);
rp++;
}
putchar('\n'); /* not in original code */
}

/*-B-----------------------------------*/

#include <stdio.h>

int main(void)
{
char rubbish[] = "I Love You\0"; /* '\0' is redundant here */
char *rp = rubbish;

while (*rp)
{
putchar(*rp);
rp++;
}
putchar('\n'); /* not in original code */
}

/*-------------------------------------*/
Dec 31 '05 #9
Broeisi wrote:
Ivan Budiselic wrote:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
Don't. It's rubbish.


Well it ain't rubbish cause it is valid C!!


Actually, it's not. In C main either takes no arguments or two
arguments, not 1.
Try compiling it..

The output will be:

I Love You
Not necessarily. It was written assuming ASCII, and not all C
implementations use ASCII.
But this code is obfuscated.... Only the real C gurus will understand it
I Guess.... not this novice guy...


Depends. It's not that difficult. Just format it properly and learn a
couple of tricks and it is simple.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Dec 31 '05 #10

"pemo" <us***********@gmail.com> wrote in message
news:dp**********@news.ox.ac.uk...

"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


Ah, but run it with some params, and it's dissapointing. Perhaps the
initialiser in the for loop would have been better this way?

for(_^=_; putchar(_++["J!Mpwf!Zpv\1"]-1); );


or even something like this?

for(_=!!_?_^_:_; putchar(_++["J!Mpwf!Zpv\1"]-1); );

Fun on c.l.c - I love it!
Dec 31 '05 #11
Broeisi wrote
(in article <Q-******************************@casema.nl>):
Ivan Budiselic wrote:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Don't. It's rubbish.


Well it ain't rubbish cause it is valid C!!


Not really no.
Try compiling it..

The output will be:

I Love You
Funny, this EBCDIC box in the corner outputs:

"Slartibartfast, system halted."

My DSK9000 outputs:

"My, what a silly little boy you are today."

Immediately afterward, it caught on fire, and now you owe me a
new one.

But this code is obfuscated.... Only the real C gurus will understand it
I Guess.... not this novice guy...


I guess not you either.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Dec 31 '05 #12
tmp123 <tm****@menta.net> wrote:
Even when "gcc" compiled with the flags -ansi and -pedantic, it
produces no errors nor warnings. Only with -std=c99 it produces 3
warnings.


You'd better try it again with -Wall. There are plenty of things
wrong with the code regardless of which standard one applies to it.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Dec 31 '05 #13
Broeisi <br*******@gmail.com> wrote:
Well it ain't rubbish cause it is valid C!!
Try compiling it..


test.c:1: warning: return type defaults to `int'
test.c: In function `main':
test.c:1: warning: implicit declaration of function `putchar'
test.c:1: warning: control reaches end of non-void function

Maybe YOU should have tried compiling it.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Dec 31 '05 #14
On 2005-12-31, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
Broeisi wrote
(in article <Q-******************************@casema.nl>):
Ivan Budiselic wrote:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
Don't. It's rubbish.


Well it ain't rubbish cause it is valid C!!


Not really no.
Try compiling it..

The output will be:

I Love You


Funny, this EBCDIC box in the corner outputs:

"Slartibartfast, system halted."

My DSK9000 outputs:

"My, what a silly little boy you are today."

Immediately afterward, it caught on fire, and now you owe me a
new one.


Other than the one-argument main(), there's no actual undefined
behavior, as far as I can tell. of course, the values of specific
characters are implementation-defined, so it's not strictly conforming -
that doesn't give the DS9K license to catch on fire, though.
Jan 1 '06 #15
Jordan Abel wrote
(in article <sl**********************@random.yi.org>):
On 2005-12-31, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
Broeisi wrote
(in article <Q-******************************@casema.nl>):
Ivan Budiselic wrote:

"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
> main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
>

Don't. It's rubbish.

Well it ain't rubbish cause it is valid C!!


Not really no.
Try compiling it..

The output will be:

I Love You


Funny, this EBCDIC box in the corner outputs:

"Slartibartfast, system halted."

My DSK9000 outputs:

"My, what a silly little boy you are today."

Immediately afterward, it caught on fire, and now you owe me a
new one.


Other than the one-argument main(), there's no actual undefined
behavior, as far as I can tell. of course, the values of specific
characters are implementation-defined, so it's not strictly conforming -
that doesn't give the DS9K license to catch on fire, though.


How many examples of UB must be present in order to obtain such
a license?

BTW, where is stdio.h?

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 1 '06 #16
On 2006-01-01, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
BTW, where is stdio.h?


The implicit declaration of putchar is correct.
Jan 1 '06 #17

Roberto Waltman wrote:
"lnzju" <ge*******@gmail.com> wrote:
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


can someone please explain as to what the initialization part of the
for loop does. How does the underscore '_' play a part in the for loop?
(in the initialization and the putchar function)?

Jan 1 '06 #18
fidlee wrote:
Roberto Waltman wrote:
"lnzju" <ge*******@gmail.com> wrote:
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


can someone please explain as to what the initialization part of the
for loop does. How does the underscore '_' play a part in the for loop?
(in the initialization and the putchar function)?


Hi,

1) "_" can be the name of a variable. In this case, it is the name of
the first parameter of the function main (usually called argc). If the
program is called without arguments, it takes value 1. (to be
practical, I will rename it to "i").

2) This variable is used as iterator of the for statement. It is
decremented at init (it takes value 0) and increment at for continue
condition (++).

3) It is used as index to char string. Taken into account that:

a[b] <==> *(a+b)

The expression i["1234"] <=> *(i+"1234") <=> "1234"[i] : i-th character
of the string.

Hope this answer was useful to you.

Kind regards.

Jan 1 '06 #19

tmp123 wrote:
fidlee wrote:
Roberto Waltman wrote:
"lnzju" <ge*******@gmail.com> wrote:
>main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


can someone please explain as to what the initialization part of the
for loop does. How does the underscore '_' play a part in the for loop?
(in the initialization and the putchar function)?


Hi,

1) "_" can be the name of a variable. In this case, it is the name of
the first parameter of the function main (usually called argc). If the
program is called without arguments, it takes value 1. (to be
practical, I will rename it to "i").

2) This variable is used as iterator of the for statement. It is
decremented at init (it takes value 0) and increment at for continue
condition (++).

3) It is used as index to char string. Taken into account that:

a[b] <==> *(a+b)

The expression i["1234"] <=> *(i+"1234") <=> "1234"[i] : i-th character
of the string.

Hope this answer was useful to you.

Kind regards.


Thanks for answering this question.That brings up my next question.
What is the significance of argv and argc in main() ?

Jan 1 '06 #20
fidlee wrote:
Thanks for answering this question.That brings up my next question.
What is the significance of argv and argc in main() ?
Hi,

A full declaration of main is:

int main (int argc, char *argv[]);

That means:

1) main returns an integer. How the operating system, the caller shell,
or any caller interprets this result, is specific of the aplication.

2) The second parameter is an array of pointers to chars, or, in usual
language, an array of strings. Each item of the array is one parameter
of the call to the program. The number of used elements in the array is
stored in argc. The first element is typically the program name.

For example, if in a shell console you execute program "foo" typing:
foo 1 hello


means argc=3, argv[0]="foo", argv[1]="1", argv[2]="hello"

Kind regards.

Jan 1 '06 #21

tmp123 wrote:
fidlee wrote:
Roberto Waltman wrote:
"lnzju" <ge*******@gmail.com> wrote:
>main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


can someone please explain as to what the initialization part of the
for loop does. How does the underscore '_' play a part in the for loop?
(in the initialization and the putchar function)?


Hi,

1) "_" can be the name of a variable. In this case, it is the name of
the first parameter of the function main (usually called argc). If the
program is called without arguments, it takes value 1. (to be
practical, I will rename it to "i").

2) This variable is used as iterator of the for statement. It is
decremented at init (it takes value 0) and increment at for continue
condition (++).

3) It is used as index to char string. Taken into account that:

a[b] <==> *(a+b)

The expression i["1234"] <=> *(i+"1234") <=> "1234"[i] : i-th character
of the string.

Hope this answer was useful to you.

Kind regards.


Thanks for answering this question.That brings up my next question.
What is the significance of argv and argc in main() ?

Jan 1 '06 #22

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


[snip]
* integer applied to string returns n-th element. (this is something I
do not know why).


The expression a[i] is defined as *(a+i); since addition is
commutative, it doesn't matter whether a is the pointer and i is the
index, or if i is the pointer and a is the index. Therefore, in C,
array indexing is commutative, so a[i] and i[a] evaluate to the same
thing.

It's fun to explain this to Ada programmers and watch their heads
explode.

Jan 1 '06 #23
Jordan Abel wrote:
On 2006-01-01, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
BTW, where is stdio.h?


The implicit declaration of putchar is correct.


And that same implicit declaration was deprecated in C99.
Jan 1 '06 #24
On 2006-01-01, Denis Kasak <de*********@gmail.com> wrote:
Jordan Abel wrote:
On 2006-01-01, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
BTW, where is stdio.h?


The implicit declaration of putchar is correct.


And that same implicit declaration was deprecated in C99.


And becomes a constraint error, not UB.
Jan 1 '06 #25
"John Bode" <jo*******@my-deja.com> writes:
[...]
The expression a[i] is defined as *(a+i); since addition is
commutative, it doesn't matter whether a is the pointer and i is the
index, or if i is the pointer and a is the index. Therefore, in C,
array indexing is commutative, so a[i] and i[a] evaluate to the same
thing.

It's fun to explain this to Ada programmers and watch their heads
explode.


Speaking as a long-time Ada programmer, I don't recall my head
exploding when I learned this. The explanation is perfectly clear,
but the rule is a bit silly. Nothing would have been lost by allowing
pointer+integer and forbidding integer+pointer.

I suppose it goes back to the days when C didn't make such a strong
distinction between pointers and integers.

--
Keith Thompson (The_Other_Keith) ks***@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.
Jan 1 '06 #26
Jordan Abel wrote
(in article <sl**********************@random.yi.org>):
On 2006-01-01, Denis Kasak <de*********@gmail.com> wrote:
Jordan Abel wrote:
On 2006-01-01, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
BTW, where is stdio.h?

The implicit declaration of putchar is correct.


And that same implicit declaration was deprecated in C99.


And becomes a constraint error, not UB.


I repeat my original question, how many UB's does one need? I
never said the above was UB either.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Jan 1 '06 #27
In article <00*****************************@news.verizon.ne t> Randy Howard <ra*********@FOOverizonBAR.net> writes:
....
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
.... Well it ain't rubbish cause it is valid C!!


Not really no.


What is wrong with it except the one argument main?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jan 2 '06 #28
In article <00*****************************@news.verizon.ne t> Randy Howard <ra*********@FOOverizonBAR.net> writes:
....
> "lnzju" <ge*******@gmail.com> wrote in message
> news:11**********************@g43g2000cwa.googlegr oups.com...
>> main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
.... How many examples of UB must be present in order to obtain such
a license?

BTW, where is stdio.h?


Not needed for "putchar", that is not a variadic function.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jan 2 '06 #29
In article <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
....
Speaking as a long-time Ada programmer, I don't recall my head
exploding when I learned this. The explanation is perfectly clear,
but the rule is a bit silly. Nothing would have been lost by allowing
pointer+integer and forbidding integer+pointer.

I suppose it goes back to the days when C didn't make such a strong
distinction between pointers and integers.


No, it goes back to the days when operators like "+" where commutative.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jan 2 '06 #30
On 2006-01-02, Dik T. Winter <Di********@cwi.nl> wrote:
In article <00*****************************@news.verizon.ne t> Randy Howard <ra*********@FOOverizonBAR.net> writes:
...
> >>>> "lnzju" <ge*******@gmail.com> wrote in message
> >>>> news:11**********************@g43g2000cwa.googlegr oups.com...
> >>>>> main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

...
> How many examples of UB must be present in order to obtain such
> a license?
>
> BTW, where is stdio.h?


Not needed for "putchar", that is not a variadic function.


Nor does it take any narrow (char, short, float) arguments or return a
type other than int, I assume you meant to add.
Jan 2 '06 #31
"Dik T. Winter" <Di********@cwi.nl> writes:
In article <ln************@nuthaus.mib.org> Keith Thompson
<ks***@mib.org> writes:
...
> Speaking as a long-time Ada programmer, I don't recall my head
> exploding when I learned this. The explanation is perfectly clear,
> but the rule is a bit silly. Nothing would have been lost by allowing
> pointer+integer and forbidding integer+pointer.
>
> I suppose it goes back to the days when C didn't make such a strong
> distinction between pointers and integers.


No, it goes back to the days when operators like "+" where commutative.


Yes, when it denotes addition of numbers.

The "+" operator is usually commutative, but it usually takes two
operands of the same type. Commutativity makes less sense when the
operands are of different types.

Some languages use "+" to denote string catenation; in such a
language, "foo" + "bar" doesn't mean the same thing as "bar" + "foo".

In my opinion (and it's nothing more than that), the C language would
be cleaner if pointer+integer were allowed (as it is now) and
integer+pointer were disallowed (making index[array] illegal). I'm
not proposing that it should be changed now, since it would break
existing code. Allowing integer+pointer isn't particularly harmful,
but I don't think it's necessary.

--
Keith Thompson (The_Other_Keith) ks***@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.
Jan 2 '06 #32
"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:Is********@cwi.nl...
In article <00*****************************@news.verizon.ne t> Randy Howard
<ra*********@FOOverizonBAR.net> writes:
...
> "lnzju" <ge*******@gmail.com> wrote in message
> news:11**********************@g43g2000cwa.googlegr oups.com...
>> main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););} ... Well it ain't rubbish cause it is valid C!!


Not really no.


What is wrong with it except the one argument main?


It seems you are arguing this is valid C because it contains "only one
undefined behavior". This is silly at best.

int main(void) {
int a;
++a;
return 0;
}

This has the same "amount" of UB, but I don't think you would argue that
it's valid C.

My original reaction was dismissive because I've noticed that novice
programmers start reading (and admiring, for some reason) obfuscated code
even before they learn how to write "normal" code, let alone robust quality
software. Reading and writing obfuscated code can maybe be a fun pastime,
but, for me at least, it's usually just disappointing - it has UB all over
the place most of the time.

--
Ivan Budiselic
ICQ# 104044323
IRC: buda @ #gamer.hr@quakenet
remove 'remove' for reply
Jan 2 '06 #33
In article <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
"Dik T. Winter" <Di********@cwi.nl> writes: ....
> I suppose it goes back to the days when C didn't make such a strong
> distinction between pointers and integers.


No, it goes back to the days when operators like "+" where commutative.


Yes, when it denotes addition of numbers.


Not only then.
The "+" operator is usually commutative, but it usually takes two
operands of the same type. Commutativity makes less sense when the
operands are of different types.
1 + 1.0 ?
Some languages use "+" to denote string catenation; in such a
language, "foo" + "bar" doesn't mean the same thing as "bar" + "foo".


As far as I know they came later than C. I think the first language
where it was possible that a + b was correct while b + a was not, was
Algol 68.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Jan 2 '06 #34
"Dik T. Winter" <Di********@cwi.nl> writes:
In article <ln************@nuthaus.mib.org> Keith Thompson
<ks***@mib.org> writes:

[...]
> The "+" operator is usually commutative, but it usually takes two
> operands of the same type. Commutativity makes less sense when the
> operands are of different types.


1 + 1.0 ?


Both operands are of type double (the left operand is promoted).

--
Keith Thompson (The_Other_Keith) ks***@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.
Jan 2 '06 #35
Dik T. Winter <Di********@cwi.nl> schrieb:
The "+" operator is usually commutative, but it usually takes two
operands of the same type. Commutativity makes less sense when the
operands are of different types.
1 + 1.0 ?


or f(x)+g(y)?

Depending on what happens inside the function f or g, this
could mean anything.
Some languages use "+" to denote string catenation; in such a
language, "foo" + "bar" doesn't mean the same thing as "bar" + "foo".


Yes, and C uses '*' for pointer dereferencing. does that mean that in

int i,k;
int *p=&i;

the following should be equivalent:

k = *p; // and
k = p*; // ?
As far as I know they came later than C. I think the first language
where it was possible that a + b was correct while b + a was not, was
Algol 68.


Depending on a and b, it can be non-commutative even in C.
That's the reason why terms like 'oder of evaluation',
'operator precedence', 'sequence point', 'side-effects' etc. exist.

Programming languages are no math packages.

Markus
Jan 2 '06 #36
Markus Becker <ye*******@web.de> writes:
Dik T. Winter <Di********@cwi.nl> schrieb:
> The "+" operator is usually commutative, but it usually takes two
> operands of the same type. Commutativity makes less sense when the
> operands are of different types.


1 + 1.0 ?


or f(x)+g(y)?

Depending on what happens inside the function f or g, this
could mean anything.


(Missing attribution; I wrote the stuff starting with 'The "+"
operator is usually commutative'.)

What happens inside f() and g() obviously affects the result, but it
doesn't affect the meaning of the "+" operator; that's determined by
their declared return types.
> Some languages use "+" to denote string catenation; in such a
> language, "foo" + "bar" doesn't mean the same thing as "bar" + "foo".
Yes, and C uses '*' for pointer dereferencing. does that mean that in

int i,k;
int *p=&i;

the following should be equivalent:

k = *p; // and
k = p*; // ?


No, why would it? That's a unary operator; commutativity is
meaningless for it. The fact that it uses the same symbol as
multiplication is not significant. Unary and binary "*" are always
unambiguously resolved during parsing.
As far as I know they came later than C. I think the first language
where it was possible that a + b was correct while b + a was not, was
Algol 68.


Depending on a and b, it can be non-commutative even in C.
That's the reason why terms like 'oder of evaluation',
'operator precedence', 'sequence point', 'side-effects' etc. exist.


When is "+" non-commutative in C (ignoring the unary "+" operator)? I
can't think of any cases where a+b and b+a have different meanings.
They might yield different results in some cases due to unspecified or
implementation-defined behavior, but in all such cases there's no
consistent difference between a+b and b+a.

--
Keith Thompson (The_Other_Keith) ks***@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.
Jan 2 '06 #37
Keith Thompson <ks***@mib.org> schrieb:
(Missing attribution; I wrote the stuff starting with 'The "+"
operator is usually commutative'.)
Sorry for that.
What happens inside f() and g() obviously affects the result, but it
doesn't affect the meaning of the "+" operator; that's determined by
their declared return types.
You are right, the '+' itself is commutative:

ff = f(x);
gg = g(y);

then ff+gg == gg+ff
> Some languages use "+" to denote string catenation; in such a
> language, "foo" + "bar" doesn't mean the same thing as "bar" + "foo".


Yes, and C uses '*' for pointer dereferencing. does that mean that in

int i,k;
int *p=&i;

the following should be equivalent:

k = *p; // and
k = p*; // ?


No, why would it? That's a unary operator; commutativity is


Right, and '+' in the context of string has nothing to do with
the mathematical definition how to add to numbers and that the
order in which they are added does not matter.

What I wanted to say (and it obviously did not come through to
you) is, that sometimes sub-optimal symbols are used/defined
for their purpose. '+' is associated with 'addition' which is
commutative, '*' is associated with division ...
meaningless for it. The fact that it uses the same symbol as
multiplication is not significant. Unary and binary "*" are always
Sure it is not significant for the purpose, if you and the compiler
know what they are doing. It's just a misleading choice of symbols.
They might yield different results in some cases due to unspecified or
implementation-defined behavior, but in all such cases there's no
consistent difference between a+b and b+a.


OK, in my example there were side effects for which, after some after-
thought the poor innocent '+'-Operator cannot be blamed. It just adds
the two values it gets, if the values are always the same, then the
result is always the same.

I stand corrected.

Markus
Jan 2 '06 #38
At about the time of 12/31/2005 11:27 AM, pemo stated the following:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Here it is a little clearer [hopefully?]

#include <stdio.h>

// x will be 1 (the name of this app would be in argv[0]) if we
// don't invoke the app with some args.
//
main(x)
{
char c;

// zero then!
//
--x;

while(c = "J!Mpwf!Zpv\1"[x])
{
// No need for the -1 if we add 1 to the literal's characters...
//
// "I Love You\1"
//
c = c - 1;

x++;

putchar(c);
}
}


You know, the code that the OP provided is the reason why I hate
wannabe's trying to be hack programmers to impress the rest of us.
Anyone who codes like that needs to be shot, not once, not twice, but
thrice. Perferably in the groin.
--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep
Jan 2 '06 #39
"Keith Thompson" <ks***@mib.org> wrote
When is "+" non-commutative in C (ignoring the unary "+" operator)? I
can't think of any cases where a+b and b+a have different meanings.
They might yield different results in some cases due to unspecified or
implementation-defined behavior, but in all such cases there's no
consistent difference between a+b and b+a.

It's not associative

a = INT_MAX;
b = 1;
c = -1;

(a + b) + c;
and
a + (b + c);

won't necessarily be the same.
Jan 3 '06 #40
"Malcolm" <re*******@btinternet.com> writes:
"Keith Thompson" <ks***@mib.org> wrote
When is "+" non-commutative in C (ignoring the unary "+" operator)? I
can't think of any cases where a+b and b+a have different meanings.
They might yield different results in some cases due to unspecified or
implementation-defined behavior, but in all such cases there's no
consistent difference between a+b and b+a.

It's not associative

a = INT_MAX;
b = 1;
c = -1;

(a + b) + c;
and
a + (b + c);

won't necessarily be the same.


Ok, but we were talking about commutativity, not associatativy.

--
Keith Thompson (The_Other_Keith) ks***@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.
Jan 3 '06 #41

"Daniel Rudy" <sp******@spamthis.net> wrote in message
news:aH****************@newssvr25.news.prodigy.net ...
At about the time of 12/31/2005 11:27 AM, pemo stated the following:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}

Here it is a little clearer [hopefully?]

#include <stdio.h>

// x will be 1 (the name of this app would be in argv[0]) if we
// don't invoke the app with some args.
//
main(x)
{
char c;

// zero then!
//
--x;

while(c = "J!Mpwf!Zpv\1"[x])
{
// No need for the -1 if we add 1 to the literal's characters...
//
// "I Love You\1"
//
c = c - 1;

x++;

putchar(c);
}
}


You know, the code that the OP provided is the reason why I hate
wannabe's trying to be hack programmers to impress the rest of us.
Anyone who codes like that needs to be shot, not once, not twice, but
thrice. Perferably in the groin.


wannabes - who, me, them, you?
Jan 3 '06 #42
pemo wrote:
"Daniel Rudy" <sp******@spamthis.net> wrote in message
news:aH****************@newssvr25.news.prodigy.net ...
At about the time of 12/31/2005 11:27 AM, pemo stated the following:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googl egroups.com...
main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
Here it is a little clearer [hopefully?]

#include <stdio.h>

// x will be 1 (the name of this app would be in argv[0]) if we
// don't invoke the app with some args.
//
main(x)
{
char c;

// zero then!
//
--x;

while(c = "J!Mpwf!Zpv\1"[x])
{
// No need for the -1 if we add 1 to the literal's characters...
//
// "I Love You\1"
//
c = c - 1;

x++;

putchar(c);
}
}


You know, the code that the OP provided is the reason why I hate
wannabe's trying to be hack programmers to impress the rest of us.
Anyone who codes like that needs to be shot, not once, not twice, but
thrice. Perferably in the groin.

wannabes - who, me, them, you?

What is that --_ in the for initializer?
Jan 4 '06 #43
Red Cent <tr**********@sbcglobal.net> writes:
pemo wrote:
"Daniel Rudy" <sp******@spamthis.net> wrote in message
news:aH****************@newssvr25.news.prodigy.net ...
At about the time of 12/31/2005 11:27 AM, pemo stated the following:
"lnzju" <ge*******@gmail.com> wrote in message
news:11**********************@g43g2000cwa.goog legroups.com...

>main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}
[snip]
What is that --_ in the for initializer?


_ is an identifier. -- is the predecrement operator.

--
Keith Thompson (The_Other_Keith) ks***@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.
Jan 4 '06 #44
Keith Thompson wrote:
Red Cent <tr**********@sbcglobal.net> writes:
pemo wrote:
"Daniel Rudy" <sp******@spamthis.net> wrote in message
news:aH****************@newssvr25.news.prodigy. net...

At about the time of 12/31/2005 11:27 AM, pemo stated the following:

>"lnzju" <ge*******@gmail.com> wrote in message
>news:11**********************@g43g2000cwa.goo glegroups.com...
>
>
>>main(_){for(--_;putchar(_++["J!Mpwf!Zpv\1"]-1););}


[snip]

What is that --_ in the for initializer?

_ is an identifier. -- is the predecrement operator.


Duh.... That's what I get for posting before looking at the entire
thread! Question already answered. But thank you!

Faux Pas #2002 using usenet... READ THE ENTIRE THREAD :)

Jan 4 '06 #45
_ can be the name of a variable. Yes, _ is a legal varible name for C.
Thanks to tmp123!

Jan 4 '06 #46
My usual problem with using argv is I forget it's an array of strings.
I either forget to cast to an int if I need it or forget to use **argv
(pointers to pointers)

Jan 4 '06 #47
tr**********@sbcglobal.net wrote:

My usual problem with using argv is I forget it's an array of strings.
I either forget to cast to an int if I need it or forget to use **argv
(pointers to pointers)


(See the numerous other posts about properly quote using Google Groups.)

Why in the world would you treat argv as an int?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Jan 4 '06 #48
Not so much treat argv as an int, but typecast it to another variable
if needed (as a number)

Jan 4 '06 #49
tr**********@sbcglobal.net writes:
Not so much treat argv as an int, but typecast it to another variable
if needed (as a number)
This was in response to:

Kenneth Brody <ke******@spamcop.net> writes: (See the numerous other posts about properly quote using Google Groups.)

Why in the world would you treat argv as an int?


I knew that only because I happened to read your response immediately
after Kenneth's article. Please read <http://cfaj.freeshell.org/google/>
and follow its advice *before* you post here again; it's important.

argv is of type char**. I can't think of any circumstances in which
it would make sense to cast it to int (i.e., (int)argv). Can you show
us an example of what you're talking about?

If you're talking about something like interpreting the string pointed
to by argv[i] as an integer, such as the string "123", that's not
typecasting (or, more properly, casting).

--
Keith Thompson (The_Other_Keith) ks***@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.
Jan 4 '06 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Simon Mansfield | last post: by
24 posts views Thread by sonnystarks | last post: by
54 posts views Thread by smnoff | last post: by
2 posts views Thread by Sean Hammond | last post: by
reply views Thread by leo001 | last post: by
reply views Thread by Anwar ali | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.