what is n1570?

[pete]

(Might be a double post, sorry if so)

In another forum I'm arguing against an outlandish claim: that
modifying a variable marked as const in a C source file generates a
run-time error because it is (as is claimed) undefined behavior.

The other guy's reference is n1570, ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
) section 6.7.3.

That section does indeed seem to support his argument. Horrifying!

So I ask you, sisters and brothers, what IS this n1570? And does it
have any force of law?

Thanks!

 

[Noob]

So I ask you, sisters and brothers, what IS this n1570?

N1570 seems to be a C1X draft.
http://en.wikipedia.org/wiki/C1X

But you know that, since it's written on the first page.
So I suppose I misunderstood your question.

 

[Shao Miller]

(Might be a double post, sorry if so)

In another forum I'm arguing against an outlandish claim: that
modifying a variable marked as const in a C source file generates a
run-time error because it is (as is claimed) undefined behavior.

Which, if any, of the following are being argued?

- That "undefined behaviour leads to a run-time error"? That seems
contradictory, as "run-time error" would appear to be a defined behaviour.

- That "modifying an object whose effective type is 'const'-qualified
results in undefined behaviour"?

- That "the word \"error\" appears within that document's section
6.7.3"? I don't see it. What's the connection with this "run-time
error" business?

The other guy's reference is n1570, ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
) section 6.7.3.

That section does indeed seem to support his argument. Horrifying!

Which point(s), in particular? 6.7.3p6 dates back to C89, as far as I know.

So I ask you, sisters and brothers, what IS this n1570? And does it
have any force of law?

I guess that probably depends on whether or not an implementation
advertises itself as conforming to it.

 

[Keith Thompson]

(Might be a double post, sorry if so)

In another forum I'm arguing against an outlandish claim: that
modifying a variable marked as const in a C source file generates a
run-time error because it is (as is claimed) undefined behavior.

The other guy's reference is n1570, ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
) section 6.7.3.

That section does indeed seem to support his argument. Horrifying!

So I ask you, sisters and brothers, what IS this n1570? And does it
have any force of law?

The C standard itself has no force of law, except perhaps indirectly
(if, say, a contract requires conformance to the C standard, and
the law enforces contracts).

n1570 is a committee draft for the upcoming C201X standard.

I fail to see how that section supports his argument, assuming
you're presenting it accurately. Certainly attempting to modify
a const-qualified object has undefined behavior; this is nothing new.

Please define what you mean by "run-time error". 6.7.3 doesn't
use that term.

 

[Seebs]

(Might be a double post, sorry if so)

In another forum I'm arguing against an outlandish claim: that
modifying a variable marked as const in a C source file generates a
run-time error because it is (as is claimed) undefined behavior.

What's outlandish about this? Modifying a const-qualified thing is indeed
undefined behavior, so far as I recall.

-s

 

[Joe Pfeiffer]

(Might be a double post, sorry if so)

In another forum I'm arguing against an outlandish claim: that
modifying a variable marked as const in a C source file generates a
run-time error because it is (as is claimed) undefined behavior.

The other guy's reference is n1570, ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
) section 6.7.3.

That section does indeed seem to support his argument. Horrifying!

I hadn't seen that standard before; I don't see where it says modifying
a const must generate a run-time error. It does say (in the footnote at
the bottom of p. 121) that the variable can be placed in read-only
memory (whether trying to change that will provoke a run-time error
vs. being silently ignored would, of course, depend on platform); in
constraint 6 on p. 122 I see it saying the behavior is undefined.

Why "horrifying"? Personally, the only thing I'd like better than a
run-time error on trying to modify a const is a compile-time error.
Whoever declared it const didn't want it modified, after all.

 

[Seebs]

I hadn't seen that standard before; I don't see where it says modifying
a const must generate a run-time error.

It doesn't.

It says that it *is* undefined behavior, which can reasonably be
called " a run-time error", it's just that one possible manifestation
of this error is that nothing unexpected happens.

-s

 

[J. J. Farrell]

In another forum I'm arguing against an outlandish claim: that
modifying a variable marked as const in a C source file generates a
run-time error because it is (as is claimed) undefined behavior.

It may or may not generate a run-time error, but it certainly causes
undefined behaviour. Why would writing to a variable which has been
declared to be read-only do anything else?

The other guy's reference is n1570, ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
) section 6.7.3.

That section does indeed seem to support his argument. Horrifying!

What is horrifying about it?

So I ask you, sisters and brothers, what IS this n1570?

It's a draft of the next C Standard, as is pretty obvious from its front
page.

And does it have any force of law?

Not of itself.

 

[Keith Thompson]

(Might be a double post, sorry if so)

In another forum I'm arguing against an outlandish claim: that
modifying a variable marked as const in a C source file generates a
run-time error because it is (as is claimed) undefined behavior.

The other guy's reference is n1570, ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
) section 6.7.3.

That section does indeed seem to support his argument. Horrifying!

So I ask you, sisters and brothers, what IS this n1570? And does it
have any force of law?

My best guess is that the "other guy" has misunderstood the meaning of
"undefined behavior". It's a common misunderstanding, but it's hardly
specific to n1570; it goes back at least to C89/C90 (and, though, I
haven't checked, I doubt that that particular wording has changed
significantly since C89/C90).

 

[Joe Pfeiffer]

It doesn't.

It says that it *is* undefined behavior, which can reasonably be
called " a run-time error", it's just that one possible manifestation
of this error is that nothing unexpected happens.

Hmmm..... from my background, "run-time error" means an exception is
raised.

 

[Seebs]

Hmmm..... from my background, "run-time error" means an exception is
raised.

Ahh! Okay, terminology.

Basically, the term-of-art "run-time error" and the plain English "run-time
error" are distinct. Modifying a const object is an error which occurs at
run-time; this does not necessarily result in a run-time error, though it
is certainly permitted to.

-s

 

[pete]

Why "horrifying"?  Personally, the only thing I'd like better than a
run-time error on trying to modify a const is a compile-time error.
Whoever declared it const didn't want it modified, after all.

Horrifying to me because I didn't understand that the const qualifier
has run-time implications. But now I got my mind right, boss.

Thanks, everybody.

 

[Lauri Alanko]

Horrifying to me because I didn't understand that the const qualifier
has run-time implications. But now I got my mind right, boss.

Note that these run-time implications are a _good_ thing. Because a
program isn't allowed to modify const storage, this means that
multiple running instances of a program (or of several programs using
the same library) can all share a single instance of this read-only
data in memory.


Lauri

 

[Keith Thompson]

Note that these run-time implications are a _good_ thing. Because a
program isn't allowed to modify const storage, this means that
multiple running instances of a program (or of several programs using
the same library) can all share a single instance of this read-only
data in memory.

Yes, but an implementation isn't *required* to do that.

A conforming implementation could generate exactly the same code
for a given program and for the same program with all occurences of
"const" removed, as long as it issues the required diagnostics for
any constraint violations.