Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   A question for this group... (http://www.velocityreviews.com/forums/t946262-a-question-for-this-group.html)

Kenny McCormack 05-15-2012 05:41 PM

A question for this group...
 
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.

--
"Remember when teachers, public employees, Planned Parenthood, NPR and PBS
crashed the stock market, wiped out half of our 401Ks, took trillions in
TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
bonuses, and paid no taxes? Yeah, me neither."

James Kuyper 05-15-2012 06:06 PM

Re: A question for this group...
 
On 05/15/2012 01:44 PM, Chine Bleu, Russie Blanche, et Khmer Rouge wrote:
> In article <jou4fd$5uh$1@news.xmission.com>,
> gazelle@shell.xmission.com (Kenny McCormack) wrote:
>
>> 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.

>
> 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.

Quentin Pope 05-15-2012 08:56 PM

Re: A question for this group...
 
On Tue, 15 May 2012 13:24:35 -0700, William Ahern wrote:

> Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> 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.

>
> 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.

Old Wolf 05-16-2012 09:31 AM

Re: A question for this group...
 
On May 16, 5:41*am, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> 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?

nick_keighley_nospam@hotmail.com 05-16-2012 10:41 AM

Re: A question for this group...
 
On Tuesday, May 15, 2012 9:56:11 PM UTC+1, Quentin Pope wrote:
> On Tue, 15 May 2012 13:24:35 -0700, William Ahern wrote:
>
> > Kenny McCormack <gazelle@shell.xmission.com> wrote:
> >> 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.

> >
> > 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.


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.

> 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.



nick_keighley_nospam@hotmail.com 05-16-2012 10:53 AM

Re: A question for this group...
 
On Tuesday, May 15, 2012 6:41:01 PM UTC+1, Kenny McCormack wrote:

> 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.


Kenny McCormack 05-16-2012 02:08 PM

Re: A question for this group...
 
In article <15497347.287.1337165607109.JavaMail.geo-discussion-forums@vbk4>,
<nick_keighley_nospam@hotmail.com> wrote:
....
>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.

Martin Shobe 05-16-2012 02:49 PM

Re: A question for this group...
 
Kenny McCormack wrote:

> In article <15497347.287.1337165607109.JavaMail.geo-discussion-forums@vbk4>,
> <nick_keighley_nospam@hotmail.com> wrote:
> ...
>>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.


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


Martin Shobe 05-16-2012 02:59 PM

Re: A question for this group...
 
Martin Shobe wrote:

> Kenny McCormack wrote:
>
>> In article <15497347.287.1337165607109.JavaMail.geo-discussion-forums@vbk4>,
>> <nick_keighley_nospam@hotmail.com> wrote:
>> ...
>>>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.

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


Kaz Kylheku 05-16-2012 04:05 PM

Re: A question for this group...
 
On 2012-05-16, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <15497347.287.1337165607109.JavaMail.geo-discussion-forums@vbk4>,
> <nick_keighley_nospam@hotmail.com> wrote:
> ...
>>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.


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.

--
If you ever need any coding done, I'm your goto man!


All times are GMT. The time now is 08:52 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.