«

On 2006-01-02, Dik T. Winter <> wrote:
> In article < t> Randy Howard <> writes:
> ...
> > >>>> "lnzju" <> wrote in message
> > >>>> news: 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.

"Dik T. Winter" <> writes:
> In article <> Keith Thompson
> <kst-> 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) kst- <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.

"Dik T. Winter" <> wrote in message
news:...
> In article < t> Randy Howard
> <> writes:
> ...
> > >> "lnzju" <> wrote in message
> > >> news: 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

In article <> Keith Thompson <kst-> writes:
> "Dik T. Winter" <> 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/

"Dik T. Winter" <> writes:
> In article <> Keith Thompson
> <kst-> 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) kst- <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.

Dik T. Winter <> 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

Markus Becker <> writes:
> Dik T. Winter <> 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) kst- <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.

Keith Thompson <kst-> 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

At about the time of 12/31/2005 11:27 AM, pemo stated the following:
> "lnzju" <> wrote in message
> news: 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

"Keith Thompson" <kst-> 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.