A question for this group...

K

Kenny McCormack

If somebody asks:

Why does it hurt when I stick my finger in a light socket?

Is it universally true that the only possible answer is:

Don't stick your fingers in light sockets.

Is it really true that an explanation of how electricity works and how your
body is a conductor (and, in particular, how the real issue is how well
grounded your body is) is never appropriate?

This seems to be the attitude of this group - see in particular the recent
"Program Output" thread.
 
J

James Kuyper

Doctor! Doctor! It hurts when I do this!

Then don't do that.

Bothering to respond to Kenny is usually a mistake, but why did you
bother making that response? It's just an example of what he's
complaining about.

If Kenny thinks that a more detailed answer is appropriate, he should
post one.
 
Q

Quentin Pope

Your light socket analogy is a perfect example. Anyone who has grown up
in an electrified civilization knows from an extremely early age that
electricity can be dangerous, and that a light socket is associated with
electricity . With this background knowledge, they would never ask "why
does it hurt when I do X" unless they were being lazy or naive. If he
weren't lazy or naive, he would have made the association with
electricity and reformed the question appropriately.

A common response to both laziness and naivety is sarcasm. It signals to
the person that they need to rethink their question in a very
fundamental way; that perhaps they're in deeper water than they think.

I went through the thread you mentioned (sans Google Groups posts). I
think the responses were just fine. They rightfully didn't talk down to
the OP. The responses were accurate, and they signaled to the OP that
his analytical investment in the issue was poor. If he can't interpret
that signal, then he's not prepared to learn anything.

I agree with this. Many posters to this group are lazy, ignorant, stupid
or all three. There's only so much time and effort it's worth putting
into helping someone swim, when natural selection seems to have chosen
that person to sink.
 
O

Old Wolf

If somebody asks:
        Why does it hurt when I stick my finger in a light socket?

Wow, how long have you been trolling this NG now,
8 years? Think the regs are suddenly going to see
the errors of their ways one day?
 
G

Guest

I agree with this. Many posters to this group are lazy, ignorant, stupid
or all three.

some are. Some aren't. I'm willing to give the benefit of the doubt. I thought the question quite reasonable. I've *written* code like that and been surprised at the result.
 
G

Guest

Why does it hurt when I stick my finger in a light socket?

Is it universally true that the only possible answer is:

Don't stick your fingers in light sockets.

it might be interesting to discuss why it hurts. But it would also be a good idea to make sure the questioner knew this was a really dangerous thing to do. More dangerous than writing code like

printf("%d %d %d",a++,a++,++a);

(I actually know someone who has a couple of fingers missing from sticking his fingers in an electrical socket.)
Is it really true that an explanation of how electricity works and how your
body is a conductor (and, in particular, how the real issue is how well
grounded your body is) is never appropriate?

This seems to be the attitude of this group - see in particular the recent
"Program Output" thread.

unsurprisingly I disagree. The C programmer language is defined by an abstract specification. Certain parts are left undefined. There the implementor has choice. It is meaningless to ask for a detailed explanation of the behaviour of a program that has strayed into such regions unless you also know a great deal about the particular implementation. With optimising compilersthis could be really hard.

For instance *I'd* expect a straitforward implementation to produce "7 6 6".. But I see I was wrong. How do you explain the output observed? Visual C++produces this output.

I suppose we could explain /why/ this has been left as UB. And discuss aliasing and sequence points and so on, but does this really help the OP?

I know Kenny knows all this stuff but I thought the question was mildly interesting. Maybe a lurker will be enlightened.
 
K

Kenny McCormack

For instance *I'd* expect a straitforward implementation to produce "7 6
6". But I see I was wrong. How do you explain the output observed?
Visual C++ produces this output.

The underlying point is that I think it *is* interesting to ask and to
answer why the OP gets the output that he gets. I also get that result
(using gcc on a Linux system) and, TBH, I can't explain it. Now, I know the
dogmatic position is that it doesn't matter what output you get, it doesn't
matter why you get the output you get, and it is a waste of time to even
think about thinking about why you get the output you get. Well, the fact
is that this whole newsgroup is a splendid waste of time. We're all wasting
time posting here - but we do it because it is fun. Quite seriously, I
can't see how anyone could disagree with that assessment.

Further, to use my light socket analogy, I think everyone knows you
shouldn't stick your finger in it (except, apparently, your friend...), but
I seriously believe that most people - even well educated people - do not
really know *why* - do not really understand how electricity works.
Therefore, I think the "why" question is much more interesting than the
stock "Don't do that!" response.

Now, I took this code and ran it two different versions of AWK - and got
expected results. GAWK gives:

% gawk 'BEGIN {a=5;print a++,a++,++a}'
5 6 8

which is easily explainable as left-to-right evaluation.

TAWK gives 7 6 6, which is also easily explainable as right-to-left evaluation.
I would expect C (at least without its doing any optimization) to give the
same, since C usually uses "cdecl", which is right-to-left (of course, yes,
Keith, I understand, none of this is mandated by the C standards).

But the C results defy logic (at least to me), and I'd be interested to find
out why this happens. Yes, Keith, we understand, it is all a waste of time,
but as noted above, we're here because the time is there to be wasted.

--
Windows 95 n. (Win-doze): A 32 bit extension to a 16 bit user interface for
an 8 bit operating system based on a 4 bit architecture from a 2 bit company
that can't stand 1 bit of competition.

Modern day upgrade --> Windows XP Professional x64: Windows is now a 64 bit
tweak of a 32 bit extension to a 16 bit user interface for an 8 bit
operating system based on a 4 bit architecture from a 2 bit company that
can't stand 1 bit of competition.
 
M

Martin Shobe

Kenny said:
The underlying point is that I think it *is* interesting to ask and to
answer why the OP gets the output that he gets. I also get that result
(using gcc on a Linux system) and, TBH, I can't explain it. Now, I know the
dogmatic position is that it doesn't matter what output you get, it doesn't
matter why you get the output you get, and it is a waste of time to even
think about thinking about why you get the output you get. Well, the fact
is that this whole newsgroup is a splendid waste of time. We're all wasting
time posting here - but we do it because it is fun. Quite seriously, I
can't see how anyone could disagree with that assessment.

Further, to use my light socket analogy, I think everyone knows you
shouldn't stick your finger in it (except, apparently, your friend...), but
I seriously believe that most people - even well educated people - do not
really know *why* - do not really understand how electricity works.
Therefore, I think the "why" question is much more interesting than the
stock "Don't do that!" response.

Now, I took this code and ran it two different versions of AWK - and got
expected results. GAWK gives:

% gawk 'BEGIN {a=5;print a++,a++,++a}'
5 6 8

which is easily explainable as left-to-right evaluation.

TAWK gives 7 6 6, which is also easily explainable as right-to-left evaluation.
I would expect C (at least without its doing any optimization) to give the
same, since C usually uses "cdecl", which is right-to-left (of course, yes,
Keith, I understand, none of this is mandated by the C standards).

But the C results defy logic (at least to me), and I'd be interested to find
out why this happens. Yes, Keith, we understand, it is all a waste of time,
but as noted above, we're here because the time is there to be wasted.

While I can't say exactly what happened, the following would be a
reasonable compilation of the above into x86 assembly code, and would
result in that particular output.

Assembly eax ebx ecx Note
-----------------------------------------
mov eax, a 5 ? ? right
inc eax 6 ? ? right side effect
mov ebx, eax 6 6 ? middle
inc eax 7 6 ? middle side effect
mov ecx, ebx 7 6 7 left
inc eax 8 6 7 left side effect
push ecx right
push ebx middle
push eax left

Martin Shobe
 
M

Martin Shobe

Martin said:
While I can't say exactly what happened, the following would be a
reasonable compilation of the above into x86 assembly code, and would
result in that particular output.

Assembly eax ebx ecx Note
-----------------------------------------
mov eax, a 5 ? ? right
inc eax 6 ? ? right side effect
mov ebx, eax 6 6 ? middle
inc eax 7 6 ? middle side effect
mov ecx, ebx 7 6 7 left
inc eax 8 6 7 left side effect
push eax right
push ebx middle
push ecx left

Martin Shobe

Oops, messed up the pushes. Fixed above.

Martin Shobe
 
K

Kaz Kylheku

The underlying point is that I think it *is* interesting to ask and to
answer why the OP gets the output that he gets. I also get that result
(using gcc on a Linux system) and, TBH, I can't explain it. Now, I know the
dogmatic position is that it doesn't matter what output you get, it doesn't
matter why you get the output you get, and it is a waste of time to even
think about thinking about why you get the output you get.

The point is that the newbie might not know that it's undefined (and may
also agree that it's a waste of time thinking about it once he knows
it is undefined).

The result is brought about by the same translation mechanism which brings
about well-defined results for well-defined code. That mechanism simply
But the C results defy logic (at least to me), and I'd be interested to find
out why this happens. Yes, Keith, we understand, it is all a waste of time,
but as noted above, we're here because the time is there to be wasted.

The C results are simply the compiler taking the liberties with regard
to function argument evaluation order. In the calling conventions on your
system, the leftmost argument goes to the top of the stack.

This means that, if push operations are used to prepare the arguments, the
rightmost argument value is pushed first.

(Even if it's not the case for non-variadic functions, you will find
that variadic function calls preserve this tradition because variadic
argument passing in C grew out of a hack which depended on the
arguments going onto the stack in that order.)

So in

a = 5;
printf("%d %d %d", a++, a++, a++)

the compiler wants to push the results in right to left order. If the object a
is reliably updated after each argument expression is evaluated, then we
get 7 6 5.

One implication of this kind of stack based passing arrangement where the
leftmost argument is at the top of the stack is that excess arguments to
functions do not matter.

printf("%d %d %d", 1, 2, 3, 4, 5);

The leftmost value is still at the top of the stack, where it is found by
the first %d. You will find that this is quite broadly portable.

Anyway, the problem with our test case is that even if there is a stack which
requires the arguments to be pushed from right to left, the evaluation doesn't
have to happen that way. The compiler could evaluate the three expressions in
a different order, save them in some temporary locations (or registers) and
then pass them in the required order. And of course, the side effects of
updating a can be deferred, wreaking havoc. We are onlly able to see 7 6 5
because the side effect updates are interleaved into the evaluation.

However, we can fix the test case so that it has unspecified behavior, rather
than undefined behavior, by using functions:

int fun(int *val)
{
return (*val)++;
}

/* ... */

a = 5;
printf("%d %d %d", fun(&a), fun(&a), fun(&a));

Now the increment is wrapped in sequence points inside the function.
Functions cannot be called in parallel in C, and so we have unspecified
behavior: there are exactly six possible evaluation orders for the three
function calls. We will see the numbers 5, 6 and 7 in the output, in one of
six possible orders.
 
O

Old Wolf

But the C results defy logic (at least to me), and I'd be interested to find
out why this happens.

You can set your compiler to output the assembly code,
which will give you some insight. As to why the compiler
outputs that assembly code, surely you will agree that
that is a question about compilers (and your specific
compiler).
 
S

Stephen Sprunk

More dangerous than writing code like

printf("%d %d %d",a++,a++,++a);
...
For instance *I'd* expect a straitforward implementation to produce "7 6 6".
But I see I was wrong. How do you explain the output observed? Visual C++
produces this output.

What output?

I get "7 6 8" with my gcc. Interestingly, at -O1 and above, it moves
those constants directly onto the stack. The assembly generated with no
optimization is not very instructive at first. However, changing the
fourth argument from "++a" to "a++", to be like the second and third,
gives this:

movl $5, -8(%ebp) ; a = 5
movl -8(%ebp), %ecx ; 4th arg
addl $1, -8(%ebp) ; postinc 4th arg
movl -8(%ebp), %eax ; 3rd arg
addl $1, -8(%ebp) ; postinc 3rd arg
movl -8(%ebp), %edx ; 2nd arg
addl $1, -8(%ebp) ; postinc 2nd arg
movl %ecx, 12(%esp)
movl %eax, 8(%esp)
movl %edx, 4(%esp)
movl $.LC0, (%esp)
call printf

Now I think I see what GCC was doing with the original version:

movl $5, -8(%ebp) ; a = 5
addl $1, -8(%ebp) ; preinc 4th arg
movl -8(%ebp), %ecx ; 3rd arg
addl $1, -8(%ebp) ; postinc 3rd arg
movl -8(%ebp), %edx ; 2nd arg
addl $1, -8(%ebp) ; postinc 2nd arg
movl -8(%ebp), %eax ; 4th arg
movl %eax, 12(%esp)
movl %ecx, 8(%esp)
movl %edx, 4(%esp)
movl $.LC0, (%esp)
call printf

It looks like GCC does any preincrements, then takes the value of
postincremented arguments, then does any postincrements, then takes the
value of preincremented args. Weird--but legal.
I suppose we could explain /why/ this has been left as UB. And discuss
aliasing and sequence points and so on, but does this really help the OP?

I don't know about this particular OP, or any others for that matter,
but seeing such responses--and wondering what they meant and why C has
so many undefined, dusty corners--has definitely helped _me_ learn more
about C and write better code.

S
 
R

Robert Miles

If somebody asks:

Why does it hurt when I stick my finger in a light socket?

Is it universally true that the only possible answer is:

Don't stick your fingers in light sockets.

Depends on what else has been placed in the light socket, such as
sharp tacks or broken glass.
 
M

Malcolm McLean

בת×ריך ×™×•× ×©×œ×™×©×™, 15 במ××™ 2012 18:41:01 UTC+1, מ×ת Kenny McCormack:
If somebody asks:

Why does it hurt when I stick my finger in a light socket?

Is it universally true that the only possible answer is:

Don't stick your fingers in light sockets.
I could explain that if you're wearing leather shoes the electricity will find earth and electrocute you, whilst if you're wearing rubber shoes you'llbe alright.

That's a reasonable explanation for a teenager, a completely irresponsible thing to tell a young child.
 
K

Kenny McCormack

בת×ריך ×™×•× ×©×œ×™×©×™, 15 במ××™ 2012 18:41:01 UTC+1, מ×ת
Kenny McCormack:
I could explain that if you're wearing leather shoes the electricity
will find earth and electrocute you, whilst if you're wearing rubber
shoes you'll be alright.

That's a reasonable explanation for a teenager, a completely
irresponsible thing to tell a young child.

Indeed. And I think that's what is so maddening about this newsgroup - that
all the regs assume that the non-regs (the "endless supply of newbies") are
morons/idiots/children. You can tell from the tone of all of their postings
(when they are not being outright insulting) that they feel they are
addressing sub-morons. Much like Mitt Romney and the rest of the GOP.

--
Is God willing to prevent evil, but not able? Then he is not omnipotent.
Is he able, but not willing? Then he is malevolent.
Is he both able and willing? Then whence cometh evil?
Is he neither able nor willing? Then why call him God?
~ Epicurus
 
G

Guest

this is a poor analogy. We're actually talking about code like
printf("%d %d %d",a++,a++,++a);
and the responses *aren't* "Don't Do That". Its "thats undefined behaviour,its outcome can't be usefyully predicted". IMHO analysing code like the above for a particular compiler is time wasted. Not just for the naive and childish poster (as you insist we treat them) but for anyone.

well I'll let you try this first with 240V 30A (european wall current). Howabout 415V? What about the inside of of a CRT? I'm a firm beliver in keeping my hands in my pockets around large voltages and currents.
Indeed. And I think that's what is so maddening about this newsgroup - that
all the regs assume that the non-regs (the "endless supply of newbies") are
morons/idiots/children.

nonsense. I learned a lot on this ng and I hope other people can too.
 
K

Kenny McCormack

this is a poor analogy. We're actually talking about code like

I heard about this time, back in, I think it was, 1988, where someone on
Usenet used an analogy to try to prove some point, and his debating
opponents at the time did *not* retort that it was a "poor analogy".

Hasn't happened since, of course...

--
Here's a simple test for Fox viewers:

1) Sit back, close your eyes, and think (Yes, I know that's hard for you).
2) Think about and imagine all of your ridiculous fantasies about Barack Obama.
3) Now, imagine that he is white. Cogitate on how absurd your fantasies
seem now.

See? That wasn't hard, was it?
 
G

Guest

I heard about this time, back in, I think it was, 1988, where someone on
Usenet used an analogy to try to prove some point, and his debating
opponents at the time did *not* retort that it was a "poor analogy".

"..to prove some point.."
leaving aside that you don't you don't prove anything by analogy...
*what* point was being proved? Maybe the analogy was sound in that case.

But in any case I am not bound by others peoples past mistakes. clc generally *does* give a reason why it is a bad idea.
 
N

Neil Cerutti

this is a poor analogy. We're actually talking about code like

printf("%d %d %d",a++,a++,++a);

and the responses *aren't* "Don't Do That". Its "thats
undefined behaviour, its outcome can't be usefyully predicted".
IMHO analysing code like the above for a particular compiler is
time wasted. Not just for the naive and childish poster (as you
insist we treat them) but for anyone.

While K&R sometimes urges learners to try out different
strategies to find out what their particular implementation does
with odd constructs, e.g., Exercise 1-2, in this case they agree
with the most common responses in this newsgroup.

They give the technical reason that constructs like this are
undefined, but they further say that knowing the result of
expressions like a = ++i on your implementation is, in fact,
evil.

The moral is that writing code that depends on order of
evaluation is a bad programming practice in any language.
Naturally, it is necessary to know what things to avoid, but if
you don't know how they are done on various machines you won't
be tempted to take advantage of a particular implementation.

Do not eat of that fruit, my friends.
 
G

Guest

"yes UBs are ok...
it is question of master 1000 pages of standard for a language..."

I don't think the C standard is that large. Its a pretty slim and
readable docuemnt (not all language standards are). An most of the
UB is fairly obvious and that that isn't usually has a good reason.
for me, i prefer a language without UBs

name one. C is actually pretty good.
or if it is possible in a set
more little it is possible...

don't understand that.
 

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

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top