Re: Strange value

From: Mike Wahler (mkwahler_at_mkwahler.net)
Date: 11/30/03 

Date: Sun, 30 Nov 2003 19:31:40 GMT

"Anon Email" <anonemail1@fastmail.fm> wrote in message
news:83b3ca3.0311292157.334e46a9@posting.google.com...
> Thanks guys.
>
> When I tweaked the code I was aware that I was passing Matter (int i)
> uninitialized arguments. I did this on purpose to see what would
> happen. I'm curious to know where the output values come from.

Anywhere. Everywhere. Nowhere. Your nasal passages. Or somewhere
else. The language definition specifically denotes the result
of such situations as *undefined*, thus there is no predictable
behavior.

> The
> first object that gets created receives an assumed value of zero,

Assumed by you. But this is an incorrect assumption.

> so I
> would have thought that the second object would also get zero.

so any deductions following from your incorrect assumption are
suspect.

>(Is
> there some sort of default initializing taking place?)

No.

>Instead it gets
> that massive

make that 'random'.

>value (2009196833), which looks like it might be the
> value limit of an integer,

Or it could be your shoe size, the age of the universe, or
some other value. The behavior is *undefined*.

> or something. The third one is 2147348480,
> the fourth is 8 and the fifth is 2009246515.

Three more random values, which are the result of *undefined*
behavior.

>
> These values look pretty random.

They are. The code which produced them is specifically identified
by the language to have *undefined* behavior.

>But I'm not convinced.

Up to you. :-)

>Regardless of
> when I compile them or how often I compile them, the values are the
> same.

If you're using a multitasking OS (e.g. Windows) try compiling/
running it again with additional tasks already running, try it
on a different machine with the same compiler, etc.
But your results, whatever they might be, still cannot be used
to identify a specific, predictable behavior, from the language
perspective.

>There must be more to it...and this is what I hope to find out.

There indeed can be much more to it (undefined behavior). The
possible manifestations of UB are theoretically limitless.
So I suppose you'll keep busy for a while. :-)

-Mike

Relevant Pages

  • Re: c doubt
    ... but the condition is failing always even array size is greater than ... zero. ... The code you have posted does not compile. ... What you have posted here is so incorrect in so many ways that it ...
    (comp.lang.c)
  • Re: GMP vs. straight C arithmetic
    ... ordinary data structures that don't impose an additonal performance ... Side-effects are another crucial part of the language. ... > Take the tree structure example I gave earlier. ... determined at compile time, is this a compile time error? ...
    (comp.programming)
  • Resolved: NOT. --WAS: Re: Static vs. Dynamic typing (big advantage or not)---WAS: c.programming:OO
    ... I certainly want more errors detected at compile time, ... > advocate reaching that goal through beefier type systems. ... in a procedural language, or in an object based language. ... Relativistic mechanics - solves the transaction thing, ...
    (comp.object)
  • Re: Teach myself C++.
    ... That seems to be an objection to the quality of implementation of ... The language IS the compilers. ... should be possible to compile some code more than once, ... I'd say that string handling is something most other languages get ...
    (sci.crypt)
  • Re: MI is sloppy
    ... at compile time, for objects whose behavior is then known ... First of all, this is a contract ... it has it's own dedicated exception. ... fix some technically incorrect programs (in manpower, performance, ...
    (comp.lang.ada)