Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is a[i] = i++ correct?

Reply
Thread Tools

Is a[i] = i++ correct?

 
 
William Hughes
Guest
Posts: n/a
 
      12-29-2007
On Dec 29, 11:14 am, Golden California Girls <(E-Mail Removed)>
wrote:
> Peter Nilsson wrote:
> > Golden California Girls <(E-Mail Removed)> wrote:
> >> Flash Gordon wrote:
> >>> ... The standard *explicitly* states that the behaviour
> >>> is undefined. ...
> >> So I'm sure we will hear about a complier that some
> >> undergrad wrote in some class that does something other
> >> than evaulate one side or the other first, ...
> >> ... No one cares because they aren't asking about that
> >> specific implementation defined example!

>
> > True. If they're in comp.lang.c, then they should only
> > be interested in what happens on the virtual C machine.

>
> Yes, an imaginary compiler on an imaginary chip! Must be why there are so many
> moron taliban ass kissing trolls just to quote the last couple of days of
> messages. People's imaginations must not match, maybe a vulcun mind meld is
> where the group should meet rather than on usenet. It would be as useful to the
> real world as what happens now.



If you had bothered to read the thread you would have noticed that
the real problem is with optimizations which may use more than one
execution
path. But the plausibility of problems is beside the point.
(Note, that such a problem might not have seemed as plausible a few
years ago when such techniques were not as widespread.) And this is
the
problem with "don't give me stuff about the imaginary machine, tell me
what real
implementations do". Implementations change, the popularity of
implementations
changes. If you only care about what happens on a few popular
implementations
today, then continue with your "real world" crap. However, those of
us in
the real world know that just because something works today, it might
not
work on a future release of a compiler *if the behaviour is
undefined*. (True.
it might not work even for defined behaviour, but this is much less
likely).
The fact that we cannot see a plausible reason that the behaviour
should
change is not important.
- William Hughes
 
Reply With Quote
 
 
 
 
Golden California Girls
Guest
Posts: n/a
 
      12-29-2007
William Hughes wrote:
> On Dec 29, 11:14 am, Golden California Girls <(E-Mail Removed)>
> wrote:
>> Peter Nilsson wrote:
>>> Golden California Girls <(E-Mail Removed)> wrote:
>>>> Flash Gordon wrote:
>>>>> ... The standard *explicitly* states that the behaviour
>>>>> is undefined. ...
>>>> So I'm sure we will hear about a complier that some
>>>> undergrad wrote in some class that does something other
>>>> than evaulate one side or the other first, ...
>>>> ... No one cares because they aren't asking about that
>>>> specific implementation defined example!
>>> True. If they're in comp.lang.c, then they should only
>>> be interested in what happens on the virtual C machine.

>> Yes, an imaginary compiler on an imaginary chip! Must be why there are so many
>> moron taliban ass kissing trolls just to quote the last couple of days of
>> messages. People's imaginations must not match, maybe a vulcun mind meld is
>> where the group should meet rather than on usenet. It would be as useful to the
>> real world as what happens now.

>
>
> If you had bothered to read the thread you would have noticed that
> the real problem is with optimizations which may use more than one
> execution
> path. But the plausibility of problems is beside the point.
> (Note, that such a problem might not have seemed as plausible a few
> years ago when such techniques were not as widespread.) And this is
> the
> problem with "don't give me stuff about the imaginary machine, tell me
> what real
> implementations do". Implementations change, the popularity of
> implementations
> changes. If you only care about what happens on a few popular
> implementations
> today, then continue with your "real world" crap. However, those of
> us in
> the real world know that just because something works today, it might
> not
> work on a future release of a compiler *if the behaviour is
> undefined*. (True.
> it might not work even for defined behaviour, but this is much less
> likely).
> The fact that we cannot see a plausible reason that the behaviour
> should
> change is not important.
> - William Hughes


I was taught long ago '70's that you never trust the output of an optimizer.
That there are 99 ways of 100 it will be wrong for your specific problem. Seems
that lesson has been lost to time.

Any complier that doesn't shout a warning at undefined statements shouldn't be
trusted.

 
Reply With Quote
 
 
 
 
William Hughes
Guest
Posts: n/a
 
      12-29-2007
On Dec 29, 1:15 pm, Golden California Girls <(E-Mail Removed)>
wrote:
> William Hughes wrote:
> > On Dec 29, 11:14 am, Golden California Girls <(E-Mail Removed)>
> > wrote:
> >> Peter Nilsson wrote:
> >>> Golden California Girls <(E-Mail Removed)> wrote:
> >>>> Flash Gordon wrote:
> >>>>> ... The standard *explicitly* states that the behaviour
> >>>>> is undefined. ...
> >>>> So I'm sure we will hear about a complier that some
> >>>> undergrad wrote in some class that does something other
> >>>> than evaulate one side or the other first, ...
> >>>> ... No one cares because they aren't asking about that
> >>>> specific implementation defined example!
> >>> True. If they're in comp.lang.c, then they should only
> >>> be interested in what happens on the virtual C machine.
> >> Yes, an imaginary compiler on an imaginary chip! Must be why there are so many
> >> moron taliban ass kissing trolls just to quote the last couple of days of
> >> messages. People's imaginations must not match, maybe a vulcun mind meld is
> >> where the group should meet rather than on usenet. It would be as useful to the
> >> real world as what happens now.

>
> > If you had bothered to read the thread you would have noticed that
> > the real problem is with optimizations which may use more than one
> > execution
> > path. But the plausibility of problems is beside the point.
> > (Note, that such a problem might not have seemed as plausible a few
> > years ago when such techniques were not as widespread.) And this is
> > the
> > problem with "don't give me stuff about the imaginary machine, tell me
> > what real
> > implementations do". Implementations change, the popularity of
> > implementations
> > changes. If you only care about what happens on a few popular
> > implementations
> > today, then continue with your "real world" crap. However, those of
> > us in
> > the real world know that just because something works today, it might
> > not
> > work on a future release of a compiler *if the behaviour is
> > undefined*. (True.
> > it might not work even for defined behaviour, but this is much less
> > likely).
> > The fact that we cannot see a plausible reason that the behaviour
> > should
> > change is not important.
> > - William Hughes

>
> I was taught long ago '70's that you never trust the output of an optimizer.
> That there are 99 ways of 100 it will be wrong for your specific problem. Seems
> that lesson has been lost to time.



In other words: when I said that no real compiler could produce the
type
of behaviour specified I was spouting bullshit, but maybe if I try to
change
the subject no one will notice this or the fact that I ignored the
point that the plausiblity of the behaviour was irrelevant.

- William Hughes


 
Reply With Quote
 
Mark McIntyre
Guest
Posts: n/a
 
      12-29-2007
On Sat, 29 Dec 2007 08:14:59 -0800, Golden California Girls wrote:

> Yes, an imaginary compiler on an imaginary chip! Must be why there are
> so many moron taliban ass kissing trolls just to quote the last couple
> of days of messages. People's imaginations must not match, maybe a
> vulcun mind meld is where the group should meet rather than on usenet.
> It would be as useful to the real world as what happens now.


okay - you're back in the killfile. Have a nice day.
 
Reply With Quote
 
Tim Smith
Guest
Posts: n/a
 
      12-29-2007
In article <(E-Mail Removed)>,
Richard Heathfield <(E-Mail Removed)> wrote:
> > ... then I claim that a[ i ] will be either a[ 2 ] or a[ 3 ],
> > depending on whether i++ gets evaluated first or last, but it must be
> > either one or the other.
> >
> > Wrong?

>
> Er, yeah, wrong. C doesn't actually guarantee this at all. But
> realistically, how could it have any other value? Well, I don't plan to
> work an example for you, but I recommend the following page, which gives
> some hard data on the various results you get from different compilers for
> similar expressions:
>
> http://www.phaedsys.demon.co.uk/chri...wengtips3a.htm


For i == 2 initially, one of those is probably realistically what you'll
get, but how about for other values of i?

Imagine an implementation using 64-bit ints, on a processor where
arithmetic is done using 32-bit operations, and the processor has
multiple hardware threads, which the compiler takes advantage of, and
imagine that i is a value such that i++ has changes to the bits in both
the lower and the upper 32-bits.

Neither increment nor assignment would be atomic for integers on this
setup, and the i in a[i] could be wildly off, using, say, the
pre-increment upper 32 bits and post increment lower 32 bits. It would
then be off by around 4 billion.

--
--Tim Smith
 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      12-30-2007
Kaz Kylheku wrote:

> C is not cast in stone. Past undefined behaviors can easily be defined
> in the future, without breaking any correctly written code.


Considering that the C99 standard has yet to be widely implemented, C is
cast in stone for most practical purposes.

--
Army1987 (Replace "NOSPAM" with "email")
 
Reply With Quote
 
Kelsey Bjarnason
Guest
Posts: n/a
 
      01-02-2008
[snips]

On Fri, 28 Dec 2007 23:45:20 +0000, Kenny McCormack wrote:

> Here, what actually happens in the real world is irrelevant. In fact,
> the real world itself is pretty much irrelevant.


Most of us write code that is expected to work in the real world.

> What matters is what
> the standard requires


Correct, as this is the only realistic guideline we have as to how the
code we write is supposed to behave. It defines exactly how our code is
expected to work, but *only* if we adhere to the standard.
 
Reply With Quote
 
dj3vande@csclub.uwaterloo.ca.invalid
Guest
Posts: n/a
 
      01-04-2008
In article <(E-Mail Removed)>,
Golden California Girls <(E-Mail Removed)> wrote:

>I was taught long ago '70's that you never trust the output of an optimizer.


You were taught wrong. (Not that that's a surprise.)
A non-broken optimizer will preserve correctness (i.e. given correct
inputs will not produce incorrect outputs), and there's a good chance
that the compiler's optimizer is better-tested than your code.
Therefore, if it produces incorrect output, there is a bug somewhere,
and it's a lot safer to bet that it's in your code than that it's in
the optimizer.

Of course, if you're in the habit of writing code that Just Happens To
Work because you compiled it with the right compiler when the moon was
in the right phase, you can expect that an optimizer will reveal some
of the bugs. That doesn't mean that your code was correct to begin
with, and it doesn't mean that the optimizer is broken.


>Any complier that doesn't shout a warning at undefined statements shouldn't be
>trusted.


I am eagerly awaiting your solution to the halting problem.


dave

 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      01-04-2008
In article <(E-Mail Removed)>,
Golden California Girls <(E-Mail Removed)> wrote:

>I was taught long ago '70's that you never trust the output of an optimizer.
>That there are 99 ways of 100 it will be wrong for your specific problem. Seems
>that lesson has been lost to time.


No, the lesson, if it was ever applicable, is not today. Many modern
compilers don't even attempt to produce reasonable code with
optimisation switched off, because they have effective, correct
optimising passes.

Optimisaation isn't some kind of magic, it's just producing better
code for a given input. Why would you not want to do that?

And as others have pointed out, the same analysis is required for
good diagnostics as is required for optimisation.

-- Richard

--
:wq
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments