beginner with programming, how to learn to debug and few C generalquestions

[Nick Keighley]

I argued (possibly without enough thought!) that atoi()
was less undesirable than gets().


I suppose I was thinking that the "likely" undefined behaviour
was less draconian for atoi() than gets(). I never use gets() and
I rarely use atoi(). In future I will be using atoi() even less!

yes, but we tend to have a mental model of what we can
reasonably expect an implementation to do. Most atoi()s return
zero if you hand them rubbish (I was quite surprised to find this
wasn't what the standard said (I have code that relies on this...)).
I hadn't considered what overflow was likely to do. :-(
gets() on the other hand with the obvious implementation is just
going to stomp all over memory. And that can't possibly be good.

I'm not sure I see the distinction between "Standard" behaviour and
"everyday" behaviour.

ok

there's behaviour in what a program does and behaviour as in a range
of permitted actual behaviours some future execution of a program may
have. I suppose the standard is defining behaviour in the "future
imperfect" sense.

I think the standard is constaining the possible behaviours of the
program.

Consider a statement like "if XYZ, the behavior is undefined."
This doesn't mean that what the program does is undefined;

I'd say that was exactly what it meant!

 it
means what the program is allowed to do by the Standard is
undefined.

sounds the same to me...

Now consider a statement like, "if I give my program an input
file of /dev/null, its bevahior is a little screwy."  This
doesn't mean the program is allowed to be a little screwy, it
means what it actually does is a little screwy.

again it seems to me a distinction without a difference

Another example:  {unsigned u = 0;  u = u+1;  return u;}  This
program fragment has "well-defined" behavior.  But if we run the
program, and the memory for u gets hit by a cosmic ray, what the
program actually does may be different from what the Standard
requires it to do.

yes but the standard is reasoning about an abstract machine.
The abstract machine is immune to cosmic rays.

The standard is saying
"if, and only if, the implementation's actual external appearance or
action corresponds with the abstract machine's external appearance
or
action does this standard apply."

Possibly the actual machine's behviour has to be a subset
of the AM's set of behaviours.

 Its behavior(1) is defined by the Standard,
but its behavior(2) is affected by cosmic rays (which are not
part of the Standard).  The terms behavior(1) and behavior(2)
clearly can't mean the same thing.

Do you see the difference I'm trying to illuminate?


No problem.  These ideas are difficult to communicate.

I'm beginning to see what you may mean. But if we start talking
about implmentations and real world hardware I think we might
be outside the standards domain of discourse.


--
Nick Keighley

"Programs must be written for people to read, and only
incidentally for machines to execute."
- Abelson & Sussman,
Structure and Interpretation of Computer Programs

 

[Nick Keighley]

ok, I'd nearly been pursuaded otherwise but now I'm back with you!
Behaviour is what a program does.


I agree

Not all the time.

why not?

Also, the observable behaviour of the physical machine
has to be the same as the required observable behviour of the abstract
machine.
yes

and that can lead to trouble (like believing atoi()'s UB is less
wicked than gets() UB...)

It depends. Sometimes people are talking about how the program is
required to behave, especially where the program will be run on multiple
different systems.

and then you want to talk about AM behaviour

yes. And sometimes we write programs where we rely on PM behaviour

Undefined behaviour in the C standard does not mean undefined on the
abstract machine,

I'd have said it does mean that!

it means undefined by the C standard, which is not the
same thing.

why not?

I dom't think the difference is what you think it is. For example, the
behaviour might be defined by the Posix standard, and that certainly is
not a physical machine!

Posix may be *an* abstract machine but it is not *the* abstract
machine. From the Standard's point of view Posix is just another
implementation machine.


--
Nick Keighley

You are in a clearing. You can see a spire in the distance.
You can also see a copy of "C Unleashed".
: INV
You have;
a DeathStation 900 laptop,
a voucher for a free pizza,
and a torch.
: TAKE BOOK
You can't. It's too heavy.
Bill Godfrey (clc)

 

[Tim Rentsch]

[...]
In the Standard, "behavior" is a description of what a program
/may/ do (ie, is allowed to do by the Standard).

I disagree. "Behavior" is what the program actually does.

And if a program doesn't behave in the way required by the standard,
the standard's statement about its behavior isn't incorrect, it's
merely inapplicable; just about everything the standard says applies
only to conforming implementations.

Let me try saying this a different way. When the Standard talks
about behavior, it is talking about how a program behaves (or
will behave) on the abstract machine.

I don't think so; I think it's talking about the program's actual
behavior. The standard specifies a range of possible actual behaviors
that a program on a conforming implementation may exhibit.

^^^

That's what I said! The standard uses the word behavior to talk
about what a program /may/ do. Not what it will do, but what it
may do.

Even the
phrase "undefined behavior" implies that there *is* some behavior that
the standard doesn't define; this can only be the actual behavior on a
real system. Nasal demons are behavior.

Furthermore, there is 5.1.2.3 p 1:

The semantic descriptions in this International Standard
describe the behavior of an abstract machine [...].

That's also what I said -- the Standard is talking about how
a program will behave on the abstract machine.

And in my opinion, the standard uses the word "behavior" in the second
sense, not the first.

That view seems at odds with your earlier "may" statement,
and also with 5.1.2.3 p 1.

 

[Tim Rentsch]

[...]
In the Standard, "behavior" is a description of what a program
/may/ do (ie, is allowed to do by the Standard).
I disagree. "Behavior" is what the program actually does.

And if a program doesn't behave in the way required by the standard,
the standard's statement about its behavior isn't incorrect, it's
merely inapplicable; just about everything the standard says applies
only to conforming implementations.

Let me try saying this a different way. When the Standard talks
about behavior, it is talking about how a program behaves (or
will behave) on the abstract machine.

Not all the time.

Perhaps not in every single instance, but in most instances.
See also 5.1.2.3 p 1.

Also, the observable behaviour of the physical machine
has to be the same as the required observable behviour of the abstract
machine.

That's nonsense, of course it doesn't. The Standard might
/specify/ that the behaviors must match, but that isn't
the same as saying they /do/ match when a program is
actually run. Statements in the Standard can't change
the laws of physics.

It depends. Sometimes people are talking about how the program is
required to behave, especially where the program will be run on multiple
different systems.

Granted. I did say "typically", specifically to avoid
meaning "always".

Undefined behaviour in the C standard does not mean undefined on the
abstract machine, it means undefined by the C standard, which is not the
same thing.

How do you reconcile this statement with 5.1.2.3 p 1?

I dom't think the difference is what you think it is. For example, the
behaviour might be defined by the Posix standard, and that certainly is
not a physical machine!

First, you agree there's a difference, which is my main point.

Second, saying "the behavior" illustrates the problem -- the word
behavior means several different things, depending on the
(sometimes implied) context in which its used. The behavior /of
an actual program execution/ is defined by the object code in
question, the physical machine instruction set, and the laws of
physics (and the OS, the actual physical machine, etc). The
behavior /as specified by the ISO Standard/ can include undefined
behavior, unspecified behavior, etc -- but these won't make the
behavior of the actual program execution be any less defined.
The behavior /that is required to be Posix compliant/ is also not
(necessarily) the same as the behavior of the actual program
execution -- hopefully it is, but Posix (like ISO C) is a set of
specifications for how a program /may/ behave, not a guarantee
(or forecast, if you like) about how a program will /actually/
behave. Saying a compiler is ISO compliant or Posix compliant
may bring an /expectation/ of a particular behavior, but the
expectation might or might not match what happens when the
program is actually run.

 

[Richard Bos]

What I think you mean is that the behavior /specification/ of atoi()
in such cases is equally undefined as the behavior specification of
gets() under analogous circumstances. It's likely that the /actual/
behavior of atoi() is much more well-defined than the behavior of
gets() in such cases.

What I think you mean is: "Stand aside, vile correctness peasant! Bother
me not with your erring on the side of caution. I shall cast all such to
the wind, for I am the Great Impervio, and I laugh in the face of
danger!" (Tell me, did I guess any more correctly than you?)
However, given the existence of strtol(), which is equivalent to atoi()
except where it is clearly superior, anyone who uses atoi() in new code
had better have a very good reason indeed if he doesn't want to be
called foolhardy.

Richard

 

[Tim Rentsch]

(e-mail address removed) (Richard Bos) writes:
There's an ambiguity because the word "behavior" has a meaning
in two different contexts, the context of the Standard, and the
context of everyday life.

In the Standard, "behavior" is a description of what a program
/may/ do (ie, is allowed to do by the Standard). [snip]
In Section 3.4, the C99 Standard defines the word "behavior" as
"external appearance or action". [snip]
From what I can tell, your
description here better describes /well-defined/ behavior, rather
than just "behavior", even as defined by the Standard.

there's behaviour in what a program does and behaviour as in a range
of permitted actual behaviours some future execution of a program may
have. I suppose the standard is defining behaviour in the "future
imperfect" sense.

Right: actual behavior, and (specification of) permitted behavior(s),
and those are two different things.

I think the standard is constaining the possible behaviours of the
program.

Yes, except the standard is constraining the possible /allowed/
behaviors; it is not constraining the set of behaviors that are
actually possible to occur.

I'd say that was exactly what it meant!


sounds the same to me...


again it seems to me a distinction without a difference


yes but the standard is reasoning about an abstract machine.
The abstract machine is immune to cosmic rays.

Yes, the Standard is describes behavior as it occurs (or would
occur) on the abstract machine. That behavior is not guaranteed
to match the behavior that actually occurs when the program is
run on a particular physical computer. The distinction is
relevant precisely because they are not guaranteed to be same,
and indeed are often different.

The standard is saying
"if, and only if, the implementation's actual external appearance or
action corresponds with the abstract machine's external appearance
or action does this standard apply."

Not quite. As the Standard uses the term, an implementation is a
piece of software. Actually running a program requires, besides
an implementation, a "data-processing system", ie, a computer
(and OS, presumably). The distinction is evident in 1 p 2:

This International Standard does not specify [...] all minimal
requirements of a data-processing system that is capable of
supporting a conforming implementation.

Possibly the actual machine's behviour has to be a subset
of the AM's set of behaviours.

If the actual machine (and OS, etc) behaves as it's supposed to,
and the implementation is conforming, then the actual program
execution /will/ behave in a way that's consistent with the ISO C
specified behavior. But an implementation can be conforming
without making any absolute guarantees about what will happen
when a program is actually run -- which is lucky, because no
absolute guarantees are possible (well, at least not non-trivial
ones), so if they were required, no implementation could be
conforming.

I'm beginning to see what you may mean. But if we start talking
about implmentations and real world hardware I think we might
be outside the standards domain of discourse.

I'm okay with talking about both, and in fact I think both are
relevant (in some contexts) here in the newsgroup; I just want
it to be clear which notion is under discussion so one is not
mistaken for the other.

 

[Tim Rentsch]

What I think you mean is: "Stand aside, vile correctness peasant! Bother
me not with your erring on the side of caution. I shall cast all such to
the wind, for I am the Great Impervio, and I laugh in the face of
danger!"

What I was trying to do (and what I intended to mean) is to point
out that "behavior" is used in two distinct senses, and that your
earlier comment is correct in one of those senses but not in the
other. I wasn't intending to make any comment one way or the
other on the advisability or inadvisability of using atoi() (as
compared to using strtol(), for example).

(Tell me, did I guess any more correctly than you?)

I believe I understood the point you were making. Do you think
you understood the point I was making?

However, given the existence of strtol(), which is equivalent to atoi()
except where it is clearly superior, anyone who uses atoi() in new code
had better have a very good reason indeed if he doesn't want to be
called foolhardy.

Nolo contendere. However that question is orthogonal to the
point I was trying to make.

 

[Flash Gordon]

ok, I'd nearly been pursuaded otherwise but now I'm back with you!
Behaviour is what a program does.

Well, it is defining behaviour in terms of what the abstract machine is
required (or sometimes permitted) to do, and that need not always be the
same as the physical machine ;-)

I agree

So do I now.

why not?

Lets start with volatile, which lays constraints on the relationship
between the actual implementation and the abstract machine, and then at
program termination all files have to be in the correct state, and
dynamics of interactive devices have to be as specified...

Actually, on looking more carefully I can't immediately see anything
else, and the paragraphs I'm refering to don't use the word "behavior"!

OK, so I'll accept that when the standard refers to behaviour it is
specifically the behaviour of the abstract machine.

yes

Actually, on looking, only specific items of observable behaviour need
to match!

and that can lead to trouble (like believing atoi()'s UB is less
wicked than gets() UB...)

Yes.

Of course other Undefined Behaviour is not always as wicked as gets(),
since sometimes it si behaviour documented by something other than the
standard and something that is required.

and then you want to talk about AM behaviour

Well, I tend to just talk about behaviour myself ;-)

yes. And sometimes we write programs where we rely on PM behaviour
Indeed.


I'd have said it does mean that!


why not?

Because the standard explicitly allows other things to define it! So it
is behaviour which *might* be defined, or might not be, just not defined
by the C standard.

Posix may be *an* abstract machine but it is not *the* abstract
machine. From the Standard's point of view Posix is just another
implementation machine.

Allowing as undefined behaviour (where the standard is explicitly
defining behaviour of the abstract machine), "...behaving during
translation or program execution in a documented manner characteristic
of the environment..." seems to me to allow the Posix standard to define
behaviour of The Abstract Machine where the C standard leave it undefined.

 

[Flash Gordon]

[...]
In the Standard, "behavior" is a description of what a program
/may/ do (ie, is allowed to do by the Standard).
I disagree. "Behavior" is what the program actually does.

And if a program doesn't behave in the way required by the standard,
the standard's statement about its behavior isn't incorrect, it's
merely inapplicable; just about everything the standard says applies
only to conforming implementations.
Let me try saying this a different way. When the Standard talks
about behavior, it is talking about how a program behaves (or
will behave) on the abstract machine.

Not all the time.

Perhaps not in every single instance, but in most instances.
See also 5.1.2.3 p 1.

See other post. I accept this.

That's nonsense, of course it doesn't. The Standard might
/specify/ that the behaviors must match, but that isn't
the same as saying they /do/ match when a program is
actually run. Statements in the Standard can't change
the laws of physics.

None of the standard requirements, as far as I'm aware, ever require
violating the laws of physics. In any case, when an implementation does
not meet the requirements placed on it by the standard that means it
does not conform, and so what the standard says is irrelevant in any case.

Granted. I did say "typically", specifically to avoid
meaning "always".

Generally people don't even realise there is a standard :-(

How do you reconcile this statement with 5.1.2.3 p 1?

That is talking about behaviour it defines, not behaviour it doesn't
define! Undefined behaviour in the C standard is explicitly allowed to
be defined by something else, and that something else does not have to
be defining the physical machine! See 3.4.3 p2, specifically "..behaving
during translation or program execution in a documented manner
characteristic of the environment..."

First, you agree there's a difference, which is my main point.

Second, saying "the behavior" illustrates the problem -- the word
behavior means several different things, depending on the
(sometimes implied) context in which its used.

Yes, and the C standard defines which meaning it is using, which is not
quite what I have first though, but there you go.

The behavior /of
an actual program execution/ is defined by the object code in
question, the physical machine instruction set, and the laws of
physics (and the OS, the actual physical machine, etc).
Yes.

The
behavior /as specified by the ISO Standard/ can include undefined
behavior, unspecified behavior, etc -- but these won't make the
behavior of the actual program execution be any less defined.

Yes and no. Some of that undefined behaviour might lead to an illegal
opcode sequence which the processor manufacturer has not bothered to
deal with and for which the actual choice of between two options might
depend on truly random (at the quantum level) factors, or possibly
slightly less random factors such as slight variations in voltage. I
have in the past come across opcodes where the manufacturer did not
define what would happen.

The behavior /that is required to be Posix compliant/ is also not
(necessarily) the same as the behavior of the actual program
execution -- hopefully it is, but Posix (like ISO C) is a set of
specifications for how a program /may/ behave, not a guarantee
(or forecast, if you like) about how a program will /actually/
behave. Saying a compiler is ISO compliant or Posix compliant
may bring an /expectation/ of a particular behavior, but the
expectation might or might not match what happens when the
program is actually run.

Actually, the statement that some implementation conforms to standards
X, Y and Z *is* a guarantee that it will behave in the way specified by
those standards (given that all of the program is defined by one
standard or another). Of course, some times things don't live up to
their guarantees, but in that case it is not compliant.

 

[Tim Rentsch]

[snip]

That's nonsense, of course it doesn't. The Standard might
/specify/ that the behaviors must match, but that isn't
the same as saying they /do/ match when a program is
actually run. Statements in the Standard can't change
the laws of physics.

None of the standard requirements, as far as I'm aware, ever require
violating the laws of physics.

Providing an absolute guarantee that an actual program execution be
consistent with the semantic description of ISO C cannot be done under
the laws of physics (at least not at we currently understand them).
If you agree that the Standard does not expect any such absolute
guarantee, then we are in agreement; if not, I'd be curious to hear
which passages in the Standard you think imply such an expectation.

In any case, when an implementation does
not meet the requirements placed on it by the standard that means it
does not conform, and so what the standard says is irrelevant in any case.

An implementation (of ISO C) is a piece of software. What it means to
meet the Standard's requirements is to say that the implementation
would behave suitably /if/ run on an appropriate data-processing
system. The Standard specifically does not address what such a
data-processing system (ie, computer/OS) might be -- 1 p 2 says:

This International Standard does not specify [...] all minimal
requirements of a data-processing system that is capable of
supporting a conforming implementation.

So saying an implementation is conforming doesn't mean an actual
program execution will behave in accordance with the Standard.

[snip]

How do you reconcile this statement with 5.1.2.3 p 1?

That is talking about behaviour it defines, not behaviour it doesn't
define!

The referenced paragraph says:

The semantic descriptions in this International Standard
describe the behavior of an abstract machine in which issues of
optimization are irrelevant.

I don't see anything here that excludes this statement from applying
to statements about implementation-defined behavior, locale-specific
behavior, unspecified behavior, or undefined behavior. What makes
you say it applies to some aspects of semantic descriptions but
not others?

Undefined behaviour in the C standard is explicitly allowed to
be defined by something else, and that something else does not have to
be defining the physical machine! See 3.4.3 p2, specifically "..behaving
during translation or program execution in a documented manner
characteristic of the environment..."

Yes, that's the point of what I was saying -- when the Standard
says "undefined behavior", it means "behavior" in the sense of
what the Standard requires; it does not mean that some other
agency can't define (or place requirements on) some other sense
of the word behavior.

[snip]

The behavior /of
an actual program execution/ is defined by the object code in
question, the physical machine instruction set, and the laws of
physics (and the OS, the actual physical machine, etc).
Yes.

The
behavior /as specified by the ISO Standard/ can include undefined
behavior, unspecified behavior, etc -- but these won't make the
behavior of the actual program execution be any less defined.

Yes and no. Some of that undefined behaviour might lead to an illegal
opcode sequence which the processor manufacturer has not bothered to
deal with and for which the actual choice of between two options might
depend on truly random (at the quantum level) factors, or possibly
slightly less random factors such as slight variations in voltage. I
have in the past come across opcodes where the manufacturer did not
define what would happen.

Behavior on the physical machine is still defined, by the instruction
set architecture, by how the architecture is implemented, by how the
implementation is realized in the manufactured components in the
particular machine in question, and ultimately by the laws of physics.
The definition may not be deterministic or especially useful, but the
behavior is still defined. For example, a program execution cannot
cause energy to be created.

Actually, the statement that some implementation conforms to standards
X, Y and Z *is* a guarantee that it will behave in the way specified by
those standards (given that all of the program is defined by one
standard or another). Of course, some times things don't live up to
their guarantees, but in that case it is not compliant.

Perhaps there are other such standards, but ISO C is not one
of them. An implementation can be conforming without providing
any guarantee of what will happen during an actual program run.
See the comments above.

 

[Keith Thompson]

Tim Rentsch wrote:

[snip]

Also, the observable behaviour of the physical machine
has to be the same as the required observable behviour of the abstract
machine.

That's nonsense, of course it doesn't. The Standard might
/specify/ that the behaviors must match, but that isn't
the same as saying they /do/ match when a program is
actually run. Statements in the Standard can't change
the laws of physics.

None of the standard requirements, as far as I'm aware, ever require
violating the laws of physics.

Providing an absolute guarantee that an actual program execution be
consistent with the semantic description of ISO C cannot be done under
the laws of physics (at least not at we currently understand them).
If you agree that the Standard does not expect any such absolute
guarantee, then we are in agreement; if not, I'd be curious to hear
which passages in the Standard you think imply such an expectation.

I'd be curious to hear which laws of physics must necessarily be
violated by a conforming C program.

In any case, when an implementation does
not meet the requirements placed on it by the standard that means it
does not conform, and so what the standard says is irrelevant in any case.

An implementation (of ISO C) is a piece of software. What it means to
meet the Standard's requirements is to say that the implementation
would behave suitably /if/ run on an appropriate data-processing
system. The Standard specifically does not address what such a
data-processing system (ie, computer/OS) might be -- 1 p 2 says:

This International Standard does not specify [...] all minimal
requirements of a data-processing system that is capable of
supporting a conforming implementation.

So saying an implementation is conforming doesn't mean an actual
program execution will behave in accordance with the Standard.

Yes it does. If an actual program execution does not behave in
accordance with the Standard, then the implementation (on that
particular system) is non-conforming. (And if, as you seem to imply,
full conformance is physically impossible, then there are no
conforming implementations in the real world.)

In practice, of course, issues like "This strictly conforming program
doesn't execute properly if the power is turned off" aren't blamed on
the implementation.

If I have a copy of an implementation that would be conforming on some
particular system, but I don't have that system (or an emulation of
it), then I don't really have a conforming implementation.

[snip]

Perhaps there are other such standards, but ISO C is not one
of them. An implementation can be conforming without providing
any guarantee of what will happen during an actual program run.
See the comments above.

The way I think of it is that the standard doesn't make guarantees; it
only imposes restrictions. The only penalty for violating one if its
restrictions is that the implementation or the program is
non-conforming.

 

[Nick Keighley]

I'd be curious to hear which laws of physics must necessarily be
violated by a conforming C program.

[I've *gotta* give this a shot]

Isn't the very concept of a deterministic computation fly in the face
of modern quantum mechanics?

<snip>

 

[James Kuyper]

I'd be curious to hear which laws of physics must necessarily be
violated by a conforming C program.

[I've *gotta* give this a shot]

Isn't the very concept of a deterministic computation fly in the face
of modern quantum mechanics?

No. From the principles of quantum mechanics, you can derive the fact
that determinism is a VERY accurate approximation to reality at the
macroscopic level. It requires very special experimental set-ups to
detect the indeterminate nature of the underlying fundamental reality.
It's so difficult to detect that there are still people working on
coming up with a way to explain those experimental results
deterministically. Therefore, computers which support C's deterministic
computation model are not in conflict with the laws of physics.

On the flip side of this argument, the smaller and faster that computer
components get, the harder it is to get them to behave reliably, because
of quantum uncertainty.

 

[Nick Keighley]

[I've *gotta* give this a shot]

Isn't the very concept of a deterministic computation fly in the face
of modern quantum mechanics?

No. From the principles of quantum mechanics, you can derive the fact
that determinism is a VERY accurate approximation to reality at the
macroscopic level. It requires very special experimental set-ups to
detect the indeterminate nature of the underlying fundamental reality.
It's so difficult to detect that there are still people working on
coming up with a way to explain those experimental results
deterministically. Therefore, computers which support C's deterministic
computation model are not in conflict with the laws of physics.

On the flip side of this argument, the smaller and faster that computer
components get, the harder it is to get them to behave reliably, because
of quantum uncertainty.

ah well, I didn't think I'd get that to fly but I felt
I had to try

 

[Tim Rentsch]

Tim Rentsch wrote:

Tim Rentsch wrote: [snip]

Also, the observable behaviour of the physical machine
has to be the same as the required observable behviour of the abstract
machine.

That's nonsense, of course it doesn't. The Standard might
/specify/ that the behaviors must match, but that isn't
the same as saying they /do/ match when a program is
actually run. Statements in the Standard can't change
the laws of physics.

None of the standard requirements, as far as I'm aware, ever require
violating the laws of physics.

Providing an absolute guarantee that an actual program execution be
consistent with the semantic description of ISO C cannot be done under
the laws of physics (at least not at we currently understand them).
If you agree that the Standard does not expect any such absolute
guarantee, then we are in agreement; if not, I'd be curious to hear
which passages in the Standard you think imply such an expectation.

I'd be curious to hear which laws of physics must necessarily be
violated by a conforming C program.

Oh, that isn't quite what I said. I said no absolute guarantees
can be made that actual program execution matches expectations
(or requirements, if you will). To give one example, the
probability is nonzero that the computer will spontaneously
tunnel through a wall and into an electrical outlet.

In any case, when an implementation does
not meet the requirements placed on it by the standard that means it
does not conform, and so what the standard says is irrelevant in any case.

An implementation (of ISO C) is a piece of software. What it means to
meet the Standard's requirements is to say that the implementation
would behave suitably /if/ run on an appropriate data-processing
system. The Standard specifically does not address what such a
data-processing system (ie, computer/OS) might be -- 1 p 2 says:

This International Standard does not specify [...] all minimal
requirements of a data-processing system that is capable of
supporting a conforming implementation.

So saying an implementation is conforming doesn't mean an actual
program execution will behave in accordance with the Standard.

Yes it does. If an actual program execution does not behave in
accordance with the Standard, then the implementation (on that
particular system) is non-conforming. [snip]

I think you're confusing two different things here, the
implementation and the physical computer it runs on. The
Standard covers only the implementation, not the physical
computer it runs on (ie, "a data-processing system that is
capable of supporting a conforming implementation"). Since the
Standard says this explicitly, and distinguishes them explicitly,
it imposes requirements only on the implementation, not on the
physical machine or on any actual program execution.

In practice, of course, issues like "This strictly conforming program
doesn't execute properly if the power is turned off" aren't blamed on
the implementation.

If I have a copy of an implementation that would be conforming on some
particular system, but I don't have that system (or an emulation of
it), then I don't really have a conforming implementation.

Not in the language of the Standard. By its description, you
would have a conforming implementation, but not a data-processing
system capable of supporting that conforming implementation. The
sentence in 1p2 clearly shows that the notion of a conforming
implementation exists independently of the system it runs on.

The way I think of it is that the standard doesn't make guarantees; it
only imposes restrictions. The only penalty for violating one if its
restrictions is that the implementation or the program is
non-conforming.

Please note that my comment about (not) providing any guarantee
is about an implementation, not about the Standard. The Standard
doesn't require that an implementation make an absolute guarantee
to be conforming, only a relative guarantee -- namely, /if/ the
implemention is run in a suitable environment, /then/ it will
behave according to the Standard's requirements. If this relative
guarantee is met, the implementation is conforming, regardless
of whether we have the supporting hardware environment or not.

 

[Tim Rentsch]

I'd be curious to hear which laws of physics must necessarily be
violated by a conforming C program.

[I've *gotta* give this a shot]

Isn't the very concept of a deterministic computation fly in the face
of modern quantum mechanics?

Basically yes. We can't eliminate the possibility
(admittedly a small probability, but still finitely
large) that a quantum mechanical catastrophe will
occur, such as all the electrons in one register
flip-flop tunnelling over to another one, wrecking
the execution state.

 

[Tim Rentsch]

I'd be curious to hear which laws of physics must necessarily be
violated by a conforming C program.

[I've *gotta* give this a shot]

Isn't the very concept of a deterministic computation fly in the face
of modern quantum mechanics?

No. From the principles of quantum mechanics, you can derive the fact
that determinism is a VERY accurate approximation to reality at the
macroscopic level. It requires very special experimental set-ups to
detect the indeterminate nature of the underlying fundamental reality.
It's so difficult to detect that there are still people working on
coming up with a way to explain those experimental results
deterministically. Therefore, computers which support C's deterministic
computation model are not in conflict with the laws of physics.

It depends on whether one is asking about a relative guarantee or
an absolute guarantee. On a relative scale, the probability of a
failure can be made pretty small (perhaps not as small as to be
arbitrarily small, but pretty doggone small!). On an absolute
scale, the probability of failure can never be reduced to zero.
Relative guarantees can be made; absolute guarantees cannot.

 

[Tim Rentsch]

I'd be curious to hear which laws of physics must necessarily be
violated by a conforming C program.

[I've *gotta* give this a shot]

Isn't the very concept of a deterministic computation fly in the face
of modern quantum mechanics?

No. From the principles of quantum mechanics, you can derive the fact
that determinism is a VERY accurate approximation to reality at the
macroscopic level. It requires very special experimental set-ups to
detect the indeterminate nature of the underlying fundamental reality.
It's so difficult to detect that there are still people working on
coming up with a way to explain those experimental results
deterministically. Therefore, computers which support C's deterministic
computation model are not in conflict with the laws of physics.

On the flip side of this argument, the smaller and faster that computer
components get, the harder it is to get them to behave reliably, because
of quantum uncertainty.

ah well, I didn't think I'd get that to fly but I felt
I had to try

Your original statement was right. James was trying
a little conversational sleight-of-hand to change
the topic from absolute determinism to approximate
determinism. But for /deterministic/ computation,
as opposed to approximately deterministic computation,
your statement is right.

 

[Richard Bos]

What I was trying to do (and what I intended to mean) is to point
out that "behavior" is used in two distinct senses, and that your
earlier comment is correct in one of those senses but not in the
other. I wasn't intending to make any comment one way or the
other on the advisability or inadvisability of using atoi() (as
compared to using strtol(), for example).

Then you didn't get my point, which is that it doesn't do to rely on
undefined behaviour when there is a perfectly defined alternative
available, _regardless_ of the likely pernicious results of the
undefined behaviour in any particular case. Where there is a better
alternative readily at hand, the difference between theoretically
allowed undefined behaviour and practically occurring undefined
behaviour is irrelevant.

In other words, it may in theory well be that atoi() is less likely to
have damaging undefined behaviour than gets(); but in practice, anyone
who even spends time pondering that likelihood instead of immediately
going for strtol() is a fool.

Richard

 

[Tim Rentsch]

Then you didn't get my point, which is that it doesn't do to rely on
undefined behaviour when there is a perfectly defined alternative
available, _regardless_ of the likely pernicious results of the
undefined behaviour in any particular case. Where there is a better
alternative readily at hand, the difference between theoretically
allowed undefined behaviour and practically occurring undefined
behaviour is irrelevant.

No, I got your point, I just had something else to say
about it.

In other words, it may in theory well be that atoi() is less likely to
have damaging undefined behaviour than gets(); but in practice, anyone
who even spends time pondering that likelihood instead of immediately
going for strtol() is a fool.

Perhaps so. But someone who doesn't distinguish between actual
behavior and Standard-specified behavior is a bigger fool.