Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #7212 > unrolled thread

what is n1570?

Back to article view | Back to comp.lang.c

Contents

  what is n1570? pete <pete@pwilson.net> - 2011-06-29 08:24 -0700
    Re: what is n1570? Noob <root@127.0.0.1> - 2011-06-29 18:08 +0200
    Re: what is n1570? Shao Miller <sha0.miller@gmail.com> - 2011-06-29 12:29 -0400
    Re: what is n1570? Keith Thompson <kst-u@mib.org> - 2011-06-29 10:26 -0700
    Re: what is n1570? Seebs <usenet-nospam@seebs.net> - 2011-06-29 17:46 +0000
    Re: what is n1570? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-29 14:37 -0600
      Re: what is n1570? Seebs <usenet-nospam@seebs.net> - 2011-06-29 21:15 +0000
        Re: what is n1570? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-06-29 20:39 -0600
          Re: what is n1570? Seebs <usenet-nospam@seebs.net> - 2011-06-30 14:52 +0000
      Re: what is n1570? pete <pete@pwilson.net> - 2011-07-01 12:43 -0700
        Re: what is n1570? Lauri Alanko <la@iki.fi> - 2011-07-01 19:50 +0000
          Re: what is n1570? Keith Thompson <kst-u@mib.org> - 2011-07-01 13:23 -0700
    Re: what is n1570? "J. J. Farrell" <jjf@bcs.org.uk> - 2011-06-29 23:32 +0100
    Re: what is n1570? Keith Thompson <kst-u@mib.org> - 2011-06-29 16:55 -0700

#7212 — what is n1570?

(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!

[toc] | [next] | [standalone]

#7213

pete wrote:

> 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.

[toc] | [prev] | [next] | [standalone]

#7215

On 6/29/2011 11:24, pete wrote:
> (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. :)

[toc] | [prev] | [next] | [standalone]

#7221

pete <pete@pwilson.net> writes:
> (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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#7224

On 2011-06-29, pete <pete@pwilson.net> wrote:
> (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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#7241

pete <pete@pwilson.net> writes:

> (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.

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

[toc] | [prev] | [next] | [standalone]

#7245

On 2011-06-29, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> 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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#7263

Seebs <usenet-nospam@seebs.net> writes:

> On 2011-06-29, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#7297

On 2011-06-30, Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> 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.

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
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#7383

On Jun 29, 4:37 pm, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:

> 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.

[toc] | [prev] | [next] | [standalone]

#7385

In article <6998523e-c479-4858-b93d-a56dc0bb3356@d7g2000vbv.googlegroups.com>,
pete  <pete@pwilson.net> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#7389

Lauri Alanko <la@iki.fi> writes:
> In article <6998523e-c479-4858-b93d-a56dc0bb3356@d7g2000vbv.googlegroups.com>,
> pete  <pete@pwilson.net> wrote:
>> 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.

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.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#7253

pete wrote:
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#7257

pete <pete@pwilson.net> writes:
> (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).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web