Skip to Content.
Sympa Menu

c-semantics - Re: [C-Semantics] C question about const

c-semantics AT lists.cs.illinois.edu

Subject: C Semantics in K Framework

List archive

Re: [C-Semantics] C question about const


Chronological Thread 
  • From: Chucky Ellison <cme AT freefour.com>
  • To: Chris Hathhorn <hathhorn AT gmail.com>, "c-semantics AT cs.illinois.edu" <c-semantics AT cs.illinois.edu>
  • Subject: Re: [C-Semantics] C question about const
  • Date: Fri, 20 Feb 2015 17:26:37 -0500
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/c-semantics/>
  • List-id: C Semantics in K Framework <c-semantics.cs.illinois.edu>

Yes, I know about that bit.  I'm pointing out that the standard doesn't necessarily say that constraint violations are undefined.  I think it's left implied, and that because they're not C programs, they are undefined.  The language it uses to explicitly say they AREN'T undefined (4:2) is weird.  They even make a point in 5.1.1.3:2 that things can be constraint violations AND undefined, which means it can be a constraint violation and NOT undefined.  Does that mean some constraint violations have defined behavior?  I think they're being pointlessly obtuse.

-Chucky

On Fri, Feb 20, 2015 at 5:21 PM, Chris Hathhorn <hathhorn AT gmail.com> wrote:
Hi Chucky,

On Fri, Feb 20, 2015 at 4:06 PM, Chucky Ellison <cme AT freefour.com> wrote:
> Doesn't being a constraint violation make it undefined?  I can't really find
> what the point of constraints are in the standard, but I've always assumed
> constraint violations were undefined.
>
> All I can find talking around it are
>
> - constraint: "restriction, either syntactic or semantic, by which the
> exposition of language elements is to be interpreted"
> and then this beast
> - If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a
> constraint or runtime-constraint is violated, the behavior is undefined.
> This seems to leave unexplained what happens if a shall or shall not
> requirement that appears INSIDE a constraint or runtime-constraint is
> violated, but its existence may imply it's not undefined.
>
> At any rate, the behavior certainly doesn't seem DEFINED.
>
> What gives?  And what do you think about how not being able to cast away
> const means we can't keep const pointers we eventually free?  Seems limiting
> to me.
>

5.1.1.3p1: "A conforming implementation shall produce at least one
diagnostic message if a preprocessing translation unit or translation
unit contains a violation of any syntax rule or constraint [...]"

Constraint violations are required to be caught by conforming
implementations (making them generally fairly easily to detect
statically).

Chris




Archive powered by MHonArc 2.6.16.

Top of Page