In article <32ad876d-2051-43d9-97a2-cd09026eeac8
@o6g2000yqj.googlegroups.com>, james.kanze@gmail.com says...

[ ... ]

> Well, it's a start, although it's still very limited.

Beyond a doubt -- I certainly didn't intend to imply that it was any
sort of panacea. At the same time, I suspect for some types of code
it's _really_ ful.

[ ... ]

> Which wasn't really what I was talking about. My point was that
> having done &v[i], you have a raw pointer, on which you can do
> pointer arithmetic, and access out of bounds without checking,
> even if the implementation checks in vector<>:perator[].

Right -- my point wasn't that the checks were the same, or anything
like that, just that (interestingly enough) taking an address happens
to break both.

> But the documentation on how VC++ detects uninitialized
> variables did seem wierd to me. For a runtime check, I'd have
> just associated an additional flag somewhere, setting it when
> the variable was set, and checking it otherwise. Perhaps the
> problem is that if initialization occurs through a pointer, the
> compiler can't generate the code to update the flag, so if the
> address is taken (which would allow such initialization), it
> just gives up.

That's my guess. For code that knows to do so, updating the flag is
easy -- but if you pass the address to the OS (for example) to read
from a file into a buffer, it's going to take a (substantial) update
to the ABI for the OS to find and update the flag appropriately.
Basically, you wouldn't be able to pass raw addresses to the OS
anymore -- you'd have to use some sort of fat pointer. I'm not sure
that's an entirely bad idea either, but I'm afraid in the open market
such an OS would tend to disappear without a trace. Too much emphasis
on still placed on raw speed for such things to survive.

OTOH, I'd almost bet that the little bit MS has done basically came
from the OS side of the house -- specifically, I'd almost bet that
some bright boy (and I do NOT mean that pejoratively at all) thought
about the number of times they've run into problems from simple
buffer overruns and such, and thought that since the programmers
weren't preventing or catching such errors dependably, it would be a
good idea to see how much they could do in the compiler instead.

--
Later,
Jerry.

this was originally on comp.lang.c++
but discussions about Undefined Behaviour seem on-topic to comp.lang.c
as well


On 16 July, 09:47, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 15, 3:18 pm, NickKeighley<nick_keighley_nos...@hotmail.com>
> wrote:
> > On 14 July, 17:09, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jul 14, 10:40 am, Stuart Redmann <DerTop...@web.de> wrote:
> > > > On 11 Jul., 00:54, Joshua Maurice <joshuamaur...@gmail.com> wrote:


> > > > [snipped discussion about run-time error when OP accessed
> > > > uninitialized memory. OP complained that C++ compiler (gcc)
> > > > could not detect this even though its warning level was set to
> > > > highest]
>
> > > > > You seem to be taking the opinion that compilers should
> > > > > catch all undefined behavior. C++ is not Java. C++'s stated
> > > > > primary design goals include
>
> > > > > - runtime performance comparable with assembly
> > > > > - don't pay for what you don't use
> > > > > - portable
> > > > > - easy to write code / programmer productivity (with less relative
> > > > > emphasis on this one IMHO)
> > > > > With these design goals in mind, it is not reasonable to
> > > > > expect a compiler to catch all possible undefined behavior
> > > > > or errors. To do that would necessarily restrict the
> > > > > language so that it's less comparable to assembly in speed
> > > > > and/or you start paying for things you don't use.
>
> > > That's not strictly true. Both the C and the C++ standards
> > > were designed so that all undefined behavior can be caught.

this surprised me


> > really? Where does it say that? Do you mean at compile time or
> > at run-time?
>
> At run-time, at the latest. (I think that there is some which
> can't be detected at compile time. But probably a lot less than
> one might think---compilers have gotten quite good at tracing
> intermodular code flow.) And it's scattered throughout the
> standard. Mostly in the form of "undefined behavior"---the
> behavior is undefined precisely so that a checking
> implementation can trap it.

I thought a fair amount of Undefined Behaviour was implicit.
Thta is no behaviour was defined therefore the behaviour was
undefined; rather there being an explicit statement that
"this behaviour is not defined". I'm pretty sure this is true
of C if not C++.


> > I'd always thought about half of UB was in the spec precisely
> > because it was too hard to detect.
>
> Too hard, no. Too expensive, perhaps: to catch all pointer
> violations, you need "fat" pointers---each pointer contains a
> current address, plus the limits, each modification of the
> pointer value verifies that the current address stays in the
> limits, and each access through the pointer verifies that it
> isn't using the end pointer (and that the pointer isn't null,
> but most hardware traps this already today).
>
> Of course, a good compiler could eliminate a certain number of
> these checks, or at least hoist them outside of a loop. But I
> don't think it could easily avoid the fact that the size of a
> pointer is multiplied by three, which makes things like copying
> significantly more expensive, and can have very negative effects
> on locality.
>
> > The other half was hardware stuff things like what the modulo
> > operator does with negative numbers
>
> That's unspecified, not undefined behavior.
>
> > gets()
>
> Takes a pointer. If the pointer contains the bounds, then it
> can easily check.

<snip>


--
Nick Keighley

"Don't spare the neurogrinders!"
Toyd Numble V1

On Jul 17, 9:15 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> this was originally on comp.lang.c++ but discussions about
> Undefined Behaviour seem on-topic to comp.lang.c as well

Given that C++ just takes over the C definition here.

> On 16 July, 09:47, James Kanze <james.ka...@gmail.com> wrote:
> > > > > > With these design goals in mind, it is not reasonable to
> > > > > > expect a compiler to catch all possible undefined behavior
> > > > > > or errors. To do that would necessarily restrict the
> > > > > > language so that it's less comparable to assembly in speed
> > > > > > and/or you start paying for things you don't use.

> > > > That's not strictly true. Both the C and the C++ standards
> > > > were designed so that all undefined behavior can be caught.

> this surprised me

On thinking about it, I probably overstated it. The context of
the discussion was things like array bounds and pointer errors,
and that's really what I had in mind. Although I think things
like i = ++i are catchable, I don't think that the intent of
making it undefined was to allow it to be caught at runtime.

There are still large categories of behavior which is undefined
expressedly to allow an implementation to catch it; arithmetic
overflow and array bounds and pointer errors are in this
category.

> > > really? Where does it say that? Do you mean at compile time or
> > > at run-time?

> > At run-time, at the latest. (I think that there is some which
> > can't be detected at compile time. But probably a lot less than
> > one might think---compilers have gotten quite good at tracing
> > intermodular code flow.) And it's scattered throughout the
> > standard. Mostly in the form of "undefined behavior"---the
> > behavior is undefined precisely so that a checking
> > implementation can trap it.

> I thought a fair amount of Undefined Behaviour was implicit.
> Thta is no behaviour was defined therefore the behaviour was
> undefined; rather there being an explicit statement that "this
> behaviour is not defined". I'm pretty sure this is true of C
> if not C++.

I don't think so. I think that almost all of the cases of
undefined behavior are explicitly stated as such. I think that
the rule of undefined behavior when the standard doesn't say
anything is mainly there to catch oversights. What "undefined
behaviors" did you have in mind?

(The typical examples of undefined behavior are all explicitely
stated as undefined: pointer and array bounds errors in the
specifications of the various operators on pointers, things like
i=++i in the header text for the Expressions section, illegal
operands to functions in the introductory text of the Library
section, and violations of what C++ calls the one definition
rule in section 3.2 in C++, and in section 6.2.7 in C.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 17, 5:19 am, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
> In article <32ad876d-2051-43d9-97a2-cd09026eeac8
> @o6g2000yqj.googlegroups.com>, james.ka...@gmail.com says...
> [ ... ]

> > Which wasn't really what I was talking about. My point was
> > that having done &v[i], you have a raw pointer, on which you
> > can do pointer arithmetic, and access out of bounds without
> > checking, even if the implementation checks in
> > vector<>:perator[].

> Right -- my point wasn't that the checks were the same, or
> anything like that, just that (interestingly enough) taking an
> address happens to break both.

Yes. The problem is that raw pointers are, well, very raw. And
that in C and C++, you have to use them in contexts where you
really shouldn't, since arrays convert to a pointer at the drop
of a hat, and array indexing is defined in terms of pointer
arithmetic. (Basically, pointer arithmetic should be reserved
for very low level code, like that inside malloc, and not be
used elsewhere. In C or C++, however, you often don't have the
choice.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 16, 11:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Jul 16, 2:09 am, James Kanze <james.ka...@gmail.com> wrote:

[...]
> > > > For most programs, we don't care about the speed.
> > > Agreed, and with the current state of the C++ industry, C++ is
> > > not the best language for every situation. Perhaps Java is be
> > > more useful for most programs.

> > Only if you can accept a fairly low level of robustness.

> This intrigues me. If you elaborate or point me to articles,
> I'd love to read up on this. IMHO, I could probably write an
> application faster in C++ and have it be "more correct" (aka
> less testing / bug-fixing time), but the same probably isn't
> true of the average developer.

I don't think it's possible in Java to reach the level of
robustness I generally require, regardless of the developer.
There are too many things that simply aren't possible, like
programming by contract (which means executable code in the
"interface", which Java doesn't allow), or RAII. Or simply
being able to abort on an assertion failure.

I think that there are pre-processors which resolve some of
Java's problems in this respect---I've heard of one for
programming by contract, for example, and I'd like to see
something like ESC/Java for C++ (and a couple of quick checks on
the web suggest that Java is evolving to address these
problems).

> I'm just curious how you're defining "robustness".

Vaguely:-). Basically, just that the code is known to be
correct, to a certain point, and that any errors will be
promptly detected and can easily be fixed.

> Are we talking real- time?

No.

> Or correct in the face of errors?

Possibly. If you accept that the correct behavior in the case
of a programming error is to abort (which is usually a
requirement in my work), then it's impossible to write code with
this behavior in Java.

> Stuff like how it's easier to leak file handles, other
> non-memory resources? Or how it's exceedingly annoying and
> difficult to write correct code in the face of "dispose" /
> "close" / "release" calls which can throw exceptions?

Partially. The lack of RAII does make certain types of errors
more likely, or harder to prevent (and missing finally blocks
are a common error in Java).

> Or are we talking about how it's impossible to write correct
> code in the face of asynchronous exceptions?

I'm not too sure what you mean here. As far as I know, neither
Java nor C++ support what I would call an asynchronous
exception. On the other hand, the fact that you can't guarantee
a function to never raise an exception in Java does mean that
you can't write really exception safe code.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

James Kanze wrote:
> On Jul 17, 9:15 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
>> [...]
>> I thought a fair amount of Undefined Behaviour was implicit.
>> Thta is no behaviour was defined therefore the behaviour was
>> undefined; rather there being an explicit statement that "this
>> behaviour is not defined". I'm pretty sure this is true of C
>> if not C++.
>
> I don't think so. I think that almost all of the cases of
> undefined behavior are explicitly stated as such. I think that
> the rule of undefined behavior when the standard doesn't say
> anything is mainly there to catch oversights. What "undefined
> behaviors" did you have in mind?
> [...]

The Committee's reasons for using three means to declare
behavior "undefined" are unknown to me, but there is no
difference in effect or in quality between "undefined due
to violation," "explicitly undefined" and "undefined by
omission." ISO/IEC 9899:1999, section 4 paragraph 2:

If a ‘‘shall’’ or ‘‘shall not’’ requirement that
appears outside of a constraint is violated, the
behavior is undefined. Undefined behavior is otherwise
indicated in this International Standard by the words
‘‘undefined behavior’’ or by the omission of any
explicit definition of behavior. There is no difference
in emphasis among these three; they all describe
‘‘behavior that is undefined’’.

The final sentence says it all (and says it normatively!):
All three means of un-definition are equivalent. (In C, at
any rate: I don't know That Other Language.)

--
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman wrote:
> James Kanze wrote:
>> On Jul 17, 9:15 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
>> wrote:
>>> [...]
>>> I thought a fair amount of Undefined Behaviour was implicit.
>>> Thta is no behaviour was defined therefore the behaviour was
>>> undefined; rather there being an explicit statement that "this
>>> behaviour is not defined". I'm pretty sure this is true of C
>>> if not C++.
>>
>> I don't think so. I think that almost all of the cases of
>> undefined behavior are explicitly stated as such. I think that
>> the rule of undefined behavior when the standard doesn't say
>> anything is mainly there to catch oversights. What "undefined
>> behaviors" did you have in mind?
>> [...]
>
> The Committee's reasons for using three means to declare
> behavior "undefined" are unknown to me, but there is no
> difference in effect or in quality between "undefined due
> to violation," "explicitly undefined" and "undefined by
> omission." ISO/IEC 9899:1999, section 4 paragraph 2:
>
> If a ‘‘shall’’ or ‘‘shall not’’ requirement that
> appears outside of a constraint is violated, the
> behavior is undefined. Undefined behavior is otherwise
> indicated in this International Standard by the words
> ‘‘undefined behavior’’ or by the omission of any
> explicit definition of behavior. There is no difference
> in emphasis among these three; they all describe
> ‘‘behavior that is undefined’’.
>
> The final sentence says it all (and says it normatively!):
> All three means of un-definition are equivalent. (In C, at
> any rate: I don't know That Other Language.)

The C++ standard does not mention "shall" as a method of indicating
undefined behavior. Section 1.3.13 says "Undefined behavior may also be
expected when this International Standard omits the description of any
explicit definition of behavior.", which strikes me as bad wording - the
phrase "may ... be expected" reflects and reinforces the misconception
that "undefined behavior" refers to a specific type of undesireable
behavior.

I think that the C++ wording provides more support for James Kanze's
opinion that the C wording does.

On 17 July, 09:40, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 17, 9:15 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
>
> > this was originally on comp.lang.c++ but discussions about
> > Undefined Behaviour seem on-topic to comp.lang.c as well
>
> Given that C++ just takes over the C definition here.

which is why I thought it was a legitimate x-post



> > On 16 July, 09:47, James Kanze <james.ka...@gmail.com> wrote:
> > > > > > > With these design goals in mind, it is not reasonable to
> > > > > > > expect a compiler to catch all possible undefined behavior
> > > > > > > or errors. To do that would necessarily restrict the
> > > > > > > language so that it's less comparable to assembly in speed
> > > > > > > and/or you start paying for things you don't use.
> > > > > That's not strictly true. Both the C and the C++ standards
> > > > > were designed so that all undefined behavior can be caught.
> > this surprised me
>
> On thinking about it, I probably overstated it. The context of
> the discussion was things like array bounds and pointer errors,
> and that's really what I had in mind. Although I think things
> like i = ++i are catchable, I don't think that the intent of
> making it undefined was to allow it to be caught at runtime.

ah, that what I was disputing. Or rather that it was took me by
surprise I'd always kind of assumed they bunged in UB just to make
the implementor's job easier.


> There are still large categories of behavior which is undefined
> expressedly to allow an implementation to catch it; arithmetic
> overflow and array bounds and pointer errors are in this
> category.
>
> > > > really? Where does it say that? Do you mean at compile time or
> > > > at run-time?
> > > At run-time, at the latest. (I think that there is some which
> > > can't be detected at compile time. But probably a lot less than
> > > one might think---compilers have gotten quite good at tracing
> > > intermodular code flow.) And it's scattered throughout the
> > > standard. Mostly in the form of "undefined behavior"---the
> > > behavior is undefined precisely so that a checking
> > > implementation can trap it.
> > I thought a fair amount of Undefined Behaviour was implicit.
> > Thta is no behaviour was defined therefore the behaviour was
> > undefined; rather there being an explicit statement that "this
> > behaviour is not defined". I'm pretty sure this is true of C
> > if not C++.
>
> I don't think so. I think that almost all of the cases of
> undefined behavior are explicitly stated as such. I think that
> the rule of undefined behavior when the standard doesn't say
> anything is mainly there to catch oversights. What "undefined
> behaviors" did you have in mind?
>
> (The typical examples of undefined behavior are all explicitely
> stated as undefined: pointer and array bounds errors in the
> specifications of the various operators on pointers, things like
> i=++i in the header text for the Expressions section, illegal
> operands to functions in the introductory text of the Library
> section, and violations of what C++ calls the one definition
> rule in section 3.2 in C++, and in section 6.2.7 in C.)

On Jul 17, 2:01am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 16, 11:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > Or are we talking about how it's impossible to write correct
> > code in the face of asynchronous exceptions?
>
> I'm not too sure what you mean here. As far as I know, neither
> Java nor C++ support what I would call an asynchronous
> exception. On the other hand, the fact that you can't guarantee
> a function to never raise an exception in Java does mean that
> you can't write really exception safe code.

http://java.sun.com/docs/books/jls/f...ml/11.doc.html

details asynchronous exceptions. I haven't thought it through
thoroughly enough, but at the very least it would be in practice
impossible to write correct code in the face of asynchronous
exceptions, and may be in-fact impossible to write it. Depends on
exactly what they call "a transfer of control" and "statements" in
regards to when an asynchronous exception can be raised. However, this
is getting a little off topic, so I guess I'll leave it at that.

"Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
news:adfbac3b-0be5-4c03-beb5-53d06179f6cf@c1g2000yqi.googlegroups.com...
this was originally on comp.lang.c++
but discussions about Undefined Behaviour seem on-topic to comp.lang.c
as well

in a cpu can not be undefinited behaviour because
if the cpu is in the state X and it read the instruction "a"
the result will be always the state X'

the same for the couple cpu-os
of the cpu-os is in the state XX and it read the instruction "a"
the result will be always the state XX'

UB exist only in the standards

In article <4a6160c1$0$47540$4fafbaef@reader1.news.tin.it>,
a@b.c.invalid says...
>
> "Nick Keighley" <nick_keighley_nospam@hotmail.com> ha scritto nel messaggio
> news:adfbac3b-0be5-4c03-beb5-53d06179f6cf@c1g2000yqi.googlegroups.com...
> this was originally on comp.lang.c++
> but discussions about Undefined Behaviour seem on-topic to comp.lang.c
> as well
>
> in a cpu can not be undefinited behaviour because
> if the cpu is in the state X and it read the instruction "a"
> the result will be always the state X'
>
> the same for the couple cpu-os
> of the cpu-os is in the state XX and it read the instruction "a"
> the result will be always the state XX'
>
> UB exist only in the standards

Not really.

First of all, some CPUs have instructions that cause undefined
results -- and while on a _specific_ CPU, the result of execution may
be predictable, different versions of the CPU, down to and including
different steppings, may give different behavior for that
instruction.

In other cases, the behavior even on a single CPU could be
unpredictable -- just for example, Intel has included a thermal diode
in some of their CPUs that's intended as high quality (albeit slow)
source of truly random numbers. While there are certainly defined
ways to access that diode, it's entirely possible that executing some
undefined instruction could do so as well -- and at least part of the
result state after doing so could be entirely unpredictable.

--
Later,
Jerry.

>but discussions about Undefined Behaviour seem on-topic to comp.lang.c
>as well
>
>in a cpu can not be undefinited behaviour because
>if the cpu is in the state X and it read the instruction "a"
>the result will be always the state X'

This isn't technically true if the CPU reads data from outside the
CPU (e.g. memory, memory-mapped I/O, I/O-port-mapped I/O, or even
the environmental sensors in the CPU for CPU temperature): the
register contents (which is part of the state) will change depending
on the outside data. Of course this is expected to happen, but the
resulting state is not fixed. It's especially true if the CPU has
a special instruction to fetch the contents of a random-number
generator, which some CPUs in the Pentium class have.

Try reading the manuals for a CPU sometime. It's not that uncommon
for there to be opcode combinations whose action is not defined
(and may differ between different models of the same CPU family).
It's also not that uncommon for a bit in a special-purpose register
to be documented as "reserved", and you're only supposed to write
back what was read out of it in the first place. Future versions
of the same CPU family may define what this bit does. Intel processor
documentation for the x86 family does this a lot, with things like
the EFLAGS register and various machine-specific registers.

Some CPUs dump out a bunch of status information for situations like
a "machine check" where some error occurred. If you mess with the
status information, then try to use it to restart where you left off,
you may end up with undefined and bizarre behavior, since some of
this relates to the internal state of undocumented stuff like
CPU pipelining, assignment of physical registers to logical registers,
etc..

>the same for the couple cpu-os
>of the cpu-os is in the state XX and it read the instruction "a"
>the result will be always the state XX'

It's much harder to make hard statements like this for a multi-tasking
OS or a multi-core CPU. Especially, external timing of things like
disk I/O or network packets can change things a lot.

>UB exist only in the standards

There are standards for CPUs and CPU families also, even if it's
only one created by the manufacturer.

"Gordon Burditt" <gordonb.fye78@burditt.org> ha scritto nel messaggio
news:zeidnRAKJvA-9_zXnZ2dnUVZ_tmdnZ2d@posted.internetamerica...
> >but discussions about Undefined Behaviour seem on-topic to comp.lang.c
>>as well
>>
>>in a cpu can not be undefinited behaviour because
>>if the cpu is in the state X and it read the instruction "a"
>>the result will be always the state X'

>>UB exist only in the standards
>
> There are standards for CPUs and CPU families also, even if it's
> only one created by the manufacturer.

i not speak about standards, i speak about a real cpu
if one 386 cpu of state X(eax=1, ebx=19, ecx=20 ...)
read the binary of "add eax, ebx"
the result will be always the state of cpu
X'(eax=20, ebx=19, ecx=20 ...)

if it is not X' is one error of cpu

if one 386 cpu of state X
read the binary of "Herbert"
and the binary of "Herbert" is not an instruciton
the result will be always Y it should be definited

In article <4a617e9c$0$832$4fafbaef@reader5.news.tin.it>,
a@b.c.invalid says...

[ ... ]

> i not speak about standards, i speak about a real cpu
> if one 386 cpu of state X(eax=1, ebx=19, ecx=20 ...)
> read the binary of "add eax, ebx"
> the result will be always the state of cpu
> X'(eax=20, ebx=19, ecx=20 ...)

Yes, but what if what's executed is 'add eax, [ebx]' instead? If ebx
happens to point to uninitialized memory, you don't know what you'll
get in eax, and it will probably vary from one invocation of the
program to the next. If ebx starts out set to zero (or another small
number, typically anything less than 4 million or so) quite a few
OSes will detect that you're accessing an illegal address, and halt
the program with some sort of error message about it doing something
illegal (of course, the exact message varies between OSes).

--
Later,
Jerry.

"Jerry Coffin" <jerryvcoffin@yahoo.com> ha scritto nel messaggio
news:MPG.24cb3ab24a1089099896d6@news.sunsite.dk...
> In article <4a617e9c$0$832$4fafbaef@reader5.news.tin.it>,
> a@b.c.invalid says...
>
> [ ... ]
>
>> i not speak about standards, i speak about a real cpu
>> if one 386 cpu of state X(eax=1, ebx=19, ecx=20 ...)
>> read the binary of "add eax, ebx"
>> the result will be always the state of cpu
>> X'(eax=20, ebx=19, ecx=20 ...)
>
> Yes, but what if what's executed is 'add eax, [ebx]' instead? If ebx
> happens to point to uninitialized memory,

i see the hardware 386cpu, the memory that can read, like a system
if this system has one state

State(0)={X(eax=20, ebx=19, ecx=20 ...)
Memory={1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,1 ...}
}
if the cpu read the instruction
'add eax, [ebx]'

State(1)={X(eax=21, ebx=19, ecx=20 ...)
Memory={1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,1,.. .}
}
there is not UB

it is like a phisical system
if i know the position in the time 0 i know the position in the next time 1

UB in that system could be only for the fail of cpu

> you don't know what you'll
> get in eax, and it will probably vary from one invocation of the
> program to the next.

it is the same of the random source
if i know all the states, and the function that descrive them:
nothing is random, all have its function that descrive it

it is like I install the same OS in 2 pc that has the same
hardware; if a program segfault if the input of sys is X
in the other Pc the same prog go to segfault
if it has the same input X.

> If ebx starts out set to zero (or another small
> number, typically anything less than 4 million or so) quite a few
> OSes will detect that you're accessing an illegal address, and halt
> the program with some sort of error message about it doing something
> illegal (of course, the exact message varies between OSes).
>
> --
> Later,
> Jerry.

On Sat, 18 Jul 2009 19:58:10 +0200, "io_x" <a@b.c.invalid> wrote:

>
>"Jerry Coffin" <jerryvcoffin@yahoo.com> ha scritto nel messaggio
>news:MPG.24cb3ab24a1089099896d6@news.sunsite.dk.. .
>> In article <4a617e9c$0$832$4fafbaef@reader5.news.tin.it>,
>> a@b.c.invalid says...
>>
>> [ ... ]
>>
>>> i not speak about standards, i speak about a real cpu
>>> if one 386 cpu of state X(eax=1, ebx=19, ecx=20 ...)
>>> read the binary of "add eax, ebx"
>>> the result will be always the state of cpu
>>> X'(eax=20, ebx=19, ecx=20 ...)
>>
>> Yes, but what if what's executed is 'add eax, [ebx]' instead? If ebx
>> happens to point to uninitialized memory,
>
>i see the hardware 386cpu, the memory that can read, like a system
>if this system has one state
>
>State(0)={X(eax=20, ebx=19, ecx=20 ...)
> Memory={1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,1 ...}
> }
>if the cpu read the instruction
>'add eax, [ebx]'
>
>State(1)={X(eax=21, ebx=19, ecx=20 ...)
> Memory={1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,1,.. .}
> }
>there is not UB
>
>it is like a phisical system
>if i know the position in the time 0 i know the position in the next time 1
>
>UB in that system could be only for the fail of cpu

Except you will never know all the states. Every time you run the
program, the clock will be different. If you are running on a typical
system, you share the CPU, memory, and OS with numerous other tasks
running "simultaneously" and their states will not be the same from
one execution to the next.

If you run the program in the morning and it produces a result of 42
and in the afternoon and it produces 24 or you recompile it on an odd
numbered Thursday during a full moon and it now produces 69 or you
change compilers and it now produces 7734, there is no way for you to
define the behavior of the program. Hence, its behavior is undefined.

--
Remove del for email

On Jul 18, 7:48 am, "io_x" <a...@b.c.invalid> wrote:
> "Nick Keighley" <nick_keighley_nos...@hotmail.com> ha scritto nel messaggionews:adfbac3b-0be5-4c03-beb5-53d06179f6cf@c1g2000yqi.googlegroups.com...
> this was originally on comp.lang.c++
> but discussions about Undefined Behaviour seem on-topic to
> comp.lang.c as well

> in a cpu can not be undefinited behaviour because if the cpu
> is in the state X and it read the instruction "a" the result
> will be always the state X'

Obviously, you've never worked on real hardware. CPU's have
certain rules which must be obeyed, and can have undefined
behavior if you violated them.

> the same for the couple cpu-os of the cpu-os is in the state
> XX and it read the instruction "a" the result will be always
> the state XX'

Ditto.

> UB exist only in the standards

Not really. What you can say is that most of the cases which
result in undefined behavior in the standard will still be
compiled to deterministic code on most most machines. What that
code does, however, is not defined, and can be pretty much
anything. Including behavior not recognized by the standard
(like generating a core dump, crashing the system or the
processor, formatting the hard disk, sending spam emails to half
the world...).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 19, 12:37 am, Barry Schwarz <schwa...@dqel.com> wrote:
> On Sat, 18 Jul 2009 19:58:10 +0200, "io_x" <a...@b.c.invalid> wrote:

> >"Jerry Coffin" <jerryvcof...@yahoo.com> ha scritto nel messaggio
> >news:MPG.24cb3ab24a1089099896d6@news.sunsite.dk.. .
> >> In article <4a617e9c$0$832$4fafb...@reader5.news.tin.it>,
> >> a...@b.c.invalid says...

> >> [ ... ]
> >it is like a phisical system if i know the position in the
> >time 0 i know the position in the next time 1

> >UB in that system could be only for the fail of cpu

> Except you will never know all the states. Every time you run the
> program, the clock will be different. If you are running on a typical
> system, you share the CPU, memory, and OS with numerous other tasks
> running "simultaneously" and their states will not be the same from
> one execution to the next.

> If you run the program in the morning and it produces a result
> of 42 and in the afternoon and it produces 24 or you recompile
> it on an odd numbered Thursday during a full moon and it now
> produces 69 or you change compilers and it now produces 7734,
> there is no way for you to define the behavior of the program.
> Hence, its behavior is undefined.

The actual speed of the gates on the chip will depend on the
temperature. Depending on this speed, the results of accessing
"inexistant" memory may vary. (Just to cite one case I've
actually encountered. The program caused the machine to hang or
not, depending on how long the machine had been turned on.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jul 17, 8:01 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> On Jul 17, 2:01 am, James Kanze <james.ka...@gmail.com> wrote:

> > On Jul 16, 11:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > > Or are we talking about how it's impossible to write
> > > correct code in the face of asynchronous exceptions?

> > I'm not too sure what you mean here. As far as I know,
> > neither Java nor C++ support what I would call an
> > asynchronous exception. On the other hand, the fact that
> > you can't guarantee a function to never raise an exception
> > in Java does mean that you can't write really exception safe
> > code.

> http://java.sun.com/docs/books/jls/f...ml/11.doc.html

> details asynchronous exceptions.

OK. It's true that things like internal errors in the virtual
machine would be asynchronously. (The C++ standard says nothing
about what happens when there is a problem in the execution
platform, so it's undefined behavior. In practice, of course,
regardless of what the language specification says, if the
execution platform doesn't work correctly, you can forget the
language standard.) The case of Thread.stop() is a special
case; they've explicitly provided a means of creating an
asynchronous exception in another thread. Current C++ doesn't
recognize threads, but I don't think that the next version
(which does support threading) will have anything similar. (The
current Java specification deprecates Thread.stop().)

> I haven't thought it through thoroughly enough, but at the
> very least it would be in practice impossible to write correct
> code in the face of asynchronous exceptions, and may be
> in-fact impossible to write it. Depends on exactly what they
> call "a transfer of control" and "statements" in regards to
> when an asynchronous exception can be raised. However, this is
> getting a little off topic, so I guess I'll leave it at that.

Writing exception safe code is on topic, and the nothrow
guarantee for a few, primitive functions is necessary in order
to do so.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

"James Kanze" <james.kanze@gmail.com> ha scritto nel messaggio
>news:164a9ba3-0ce2-4386-b64e-aca4299f7f94@s15g2000yqs.googlegroups.com...
>On Jul 19, 12:37 am, Barry Schwarz <schwa...@dqel.com> wrote:
>> On Sat, 18 Jul 2009 19:58:10 +0200, "io_x" <a...@b.c.invalid> wrote:
>> >"Jerry Coffin" <jerryvcof...@yahoo.com> ha scritto nel messaggio
>> >news:MPG.24cb3ab24a1089099896d6@news.sunsite.dk.. .
>> >> In article <4a617e9c$0$832$4fafb...@reader5.news.tin.it>,
>> >> a...@b.c.invalid says...

>> >> [ ... ]
>> >it is like a phisical system if i know the position in the
> >time 0 i know the position in the next time 1

>> >UB in that system could be only for the fail of cpu

>> Except you will never know all the states. Every time you run the
>> program, the clock will be different. If you are running on a typical
>> system, you share the CPU, memory, and OS with numerous other tasks
>> running "simultaneously" and their states will not be the same from
>> one execution to the next.

>> If you run the program in the morning and it produces a result
>> of 42 and in the afternoon and it produces 24 or you recompile
>> it on an odd numbered Thursday during a full moon and it now
>> produces 69 or you change compilers and it now produces 7734,
>> there is no way for you to define the behavior of the program.
>> Hence, its behavior is undefined.

>The actual speed of the gates on the chip will depend on the
>temperature. Depending on this speed, the results of accessing
>"inexistant" memory may vary. (Just to cite one case I've
>actually encountered. The program caused the machine to hang or
>not, depending on how long the machine had been turned on.)


and now you too, know what have to go in a PC that is ok,
and what have to go in a PC is not ok.
there is the good way (full controll) and there
is the not good way (UBs)

io_x wrote:
> "Gordon Burditt" <gordonb.fye78@burditt.org> ha scritto nel messaggio
> news:zeidnRAKJvA-9_zXnZ2dnUVZ_tmdnZ2d@posted.internetamerica...
>>> but discussions about Undefined Behaviour seem on-topic to comp.lang.c
>>> as well
>>>
>>> in a cpu can not be undefinited behaviour because
>>> if the cpu is in the state X and it read the instruction "a"
>>> the result will be always the state X'
>
>>> UB exist only in the standards
>> There are standards for CPUs and CPU families also, even if it's
>> only one created by the manufacturer.
>
> i not speak about standards, i speak about a real cpu
> if one 386 cpu of state X(eax=1, ebx=19, ecx=20 ...)
> read the binary of "add eax, ebx"
> the result will be always the state of cpu
> X'(eax=20, ebx=19, ecx=20 ...)

[...]

So, what you are saying is, if you execute a well-defined operation, you get
well-defined results? Nothing new here.

Perhaps you only have experience with the 386 CPU?

I have used CPUs which actually execute two instructions in parallel. If
you do something such that one of those instructions reads from address X
and the other writes to address X, "bad things" can happen. I don't know if
those "bad things" are defined or not, however I do know that the C
compilers I have used know to avoid such constructs, and will insert a no-op
into one of the instructions if necessary.

Even something which is well defined in the high-level language could do
"bad things" if the compiler didn't take this into account.

Consider:

int a,b;
...
a = b++;

What would happen if the compiler generated something like this?

load r1,b
incr b

If b initially holds the value 42, what value gets stored in register r1?
Remember, both instructions are executed in parallel.

--
Kenneth Brody

On Jul 19, 4:23am, James Kanze <james.ka...@gmail.com> wrote:
> On Jul 17, 8:01 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
>
> > On Jul 17, 2:01 am, James Kanze <james.ka...@gmail.com> wrote:
> > > On Jul 16, 11:34 pm, Joshua Maurice <joshuamaur...@gmail.com> wrote:
> > > > Or are we talking about how it's impossible to write
> > > > correct code in the face of asynchronous exceptions?
> > > I'm not too sure what you mean here. As far as I know,
> > > neither Java nor C++ support what I would call an
> > > asynchronous exception. On the other hand, the fact that
> > > you can't guarantee a function to never raise an exception
> > > in Java does mean that you can't write really exception safe
> > > code.
> >http://java.sun.com/docs/books/jls/f...ml/11.doc.html
> > details asynchronous exceptions.
>
> OK. It's true that things like internal errors in the virtual
> machine would be asynchronously. (The C++ standard says nothing
> about what happens when there is a problem in the execution
> platform, so it's undefined behavior. In practice, of course,
> regardless of what the language specification says, if the
> execution platform doesn't work correctly, you can forget the
> language standard.) The case of Thread.stop() is a special
> case; they've explicitly provided a means of creating an
> asynchronous exception in another thread. Current C++ doesn't
> recognize threads, but I don't think that the next version
> (which does support threading) will have anything similar. (The
> current Java specification deprecates Thread.stop().)
>
> > I haven't thought it through thoroughly enough, but at the
> > very least it would be in practice impossible to write correct
> > code in the face of asynchronous exceptions, and may be
> > in-fact impossible to write it. Depends on exactly what they
> > call "a transfer of control" and "statements" in regards to
> > when an asynchronous exception can be raised. However, this is
> > getting a little off topic, so I guess I'll leave it at that.
>
> Writing exception safe code is on topic, and the nothrow
> guarantee for a few, primitive functions is necessary in order
> to do so.

From that little except, I'm not clear on exactly when a Java
asynchronous exception can be thrown. I'm not sure what my no-throwing
primitives are, if any. Then again, it's sort of an anal point. As you
noted, if the platform encounters a problem it can't handle, your
program is FUBAR anyway. I do strongly dislike how the stack will be
unwound if the JVM hits some kinds of internal errors (see finally
blocks).

jacob navia wrote:

> And last but not least: Is there a good book in C++ debugging?

I don't know if it's good but I just came across this reference:

Zeller - Why Programs Fail
http://www.whyprogramsfail.com/


Martin

--
Quidquid latine scriptum est, altum videtur.