C Semantics in K Framework

[Chucky Ellison <cme AT freefour.com>]

Okay one more point that my example missed.  The internet (

  http://stackoverflow.com/questions/2819535/unable-to-free-const-pointers-in-c

  http://bytes.com/topic/c/answers/217935-passing-const-void-free

  etc etc etc

  and http://yarchive.net/comp/const.html where linus rants

) seems to think it's okay to add a cast that removes the const, like

// p1

const int* p = malloc(sizeof(*p)); // totally kosher

int* q = (int*)p; // undefined (imho)

Now maybe I am wrong and the above code really is defined.  I saw that 6.5.4:3 says "Conversions that involve pointers, other than where permitted by the constraints of 6.5.16.1, shall be specified by means of an explicit cast."  It certainly seems to be saying you can use casting to prevent the warnings required by the constraints, but that doesn't magically give semantics to such conversions.  6.3.2.3 still does not list removing const from a pointer as a thing that is allowed.  Therefore, it seems undefined to me.  Would you agree?  If not, where is such a conversion given semantics?

If we agree it's undefined, then it's unfortunate that free() takes a pointer to non-const.  It means people can't write this:

const int* p; // my program shall never modify the int that p points to

p = malloc(sizeof(*p)); // totally kosher

...

free((int*)p); // undefined!

-Chucky

On Fri, Feb 20, 2015 at 8:44 PM, Derek M Jones <derek AT knosof.co.uk> wrote:

Chucky,

Doesn't being a constraint violation make it undefined?  I can't really

A constraint violation means the that program is erroneous and need not
be translated by a conforming implementation.

Of course a conforming implementation can translation an erroneous
program, but the behavior is undefined (3.4.3p1).  There is nothing
that says a C compiler cannot process Fortran source as if it were
a Fortran compiler.

What is special about your example?

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.

-Chucky

On Thu, Feb 19, 2015 at 9:47 AM, Derek M Jones <derek AT knosof.co.uk> wrote:

Chucky,

Good to hear from you.  Hope you are having fun.

  int * p3 = p2; // I think this is undefined, since the case is not listed

in 6.3.2.3 or anywhere else I can tell

Its a constraint violation, 6.7.8p11 -> 6.5.16.1p1


--
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com

--
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com